Re: Blog post: Demystifying Garbage Collectors
Era Scarecrow, el 13 de October a las 21:18 me escribiste:
Does D include an index to bitmaps specifying which offsets in a
given memory block (say a class or a struct) of which fields
actually would point to memory? With the strong possibility of
working with manual pointer management it is possible it's not as
useful as it could be; But may be considered when making a GC. Who
knows, I may try my hand at it.
//some pseudo random number generator class
class Prng {
int seed;
int[] cached;
//mem location as good as any for an initial seed,
//maybe xor against time/date
this() {seed = cast(int) this;}
}
The above may have a bitmap indexed to 0_010b (or an index so
enum {nil, charArray, intArray} and thus [nil, intArray, nil], so it
would skip the ints and only check the only that actually would
contains a pointer. It could also effectively hold additional
information on the type for further indexing, so when it sees
'cached' it will know it's an array, but if it was an array to
Objects, then it would scan every part of that inner array mentioned
for further references.
There was at least one attempt to make the GC partially precise, which
is what you are suggesting. I've implemented a GC for D which goal was
to make it concurrent (to minimize pause times) but I also made use of
the information about types when available. The main advantage of this
is not really scanning less memory, but avoiding memory leaks by holding
memory cells as if they were alive when they really aren't, which was
a big problem in D now (and maybe it still is, I'm not very updated in
the state of D2's GC, but I'm almost sure there is still no type
information available to the GC in D2).
Unfortunately neither the patch to make DMD emit information about types
nor my GC were ever merged to D2, only Tango accepted the GC but since
DMD never accepted the patches emitting type information, the GC is not
precise in practice.
It worth mentioning that there is one bit of type information. If you
class/struct doesn't have *any* pointers, the memory cell where it is
stored will be marked as it doesn't have to be scanned. Same for arrays
of data that's known not to have pointers (like one of this class/struct
or ints, or floats for example).
There is even a bug report about this, if you want to take a look:
http://d.puremagic.com/issues/show_bug.cgi?id=3463
BTW, there is no need to follow arrays in any special way, dynamic
arrays are just a pointer and a size_t and the GC will follow the
pointer anyway. The array is allocated in a memory cell that would have
it's own type information and thus can be scanned (or ignored)
as needed.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
22% of the time a pizza will arrive faster than an ambulance in
Great-Britain
Re: Mono-D v0.4.1.5 Fixes
On Saturday, 13 October 2012 at 13:17:52 UTC, alex wrote: Hi everyone, Just released a new Mono-D version that features couple of bigger sort of fixes.. The download: http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.5_MD3.0.4.7.mpack The changelog: http://mono-d.alexanderbothe.com/?p=634 The blog: http://mono-d.alexanderbothe.com The issues: https://github.com/aBothe/Mono-D/issues Cheers, Alex Great work, thanks.
Re: D1 D2 alpha's for Win64
Walter Bright: http://ftp.digitalmars.com/dmd2beta.zip Be the first kid on your block to build a dmd Win64 app! The changelog section is not in good state, it misses parts and newlines. Bye, bearophile
Re: D1 D2 alpha's for Win64
On 10/14/12, Walter Bright newshou...@digitalmars.com wrote: Be the first kid on your block to build a dmd Win64 app! But this is without Phobos support? D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(317): Error: module string is in file 'std\c\string.d' which cannot be read I can't test much if Phobos can't be used. :)
Re: D1 D2 alpha's for Win64
On 10/14/2012 3:27 PM, Andrej Mitrovic wrote: D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(317): Error: module string is in file 'std\c\string.d' which cannot be read Fixed.
Re: D1 D2 alpha's for Win64
On 10/15/12, Walter Bright newshou...@digitalmars.com wrote: On 10/14/2012 3:27 PM, Andrej Mitrovic wrote: D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(317): Error: module string is in file 'std\c\string.d' which cannot be read Fixed. Ok so we're only supposed to compile with -c when using -m64? I don't suppose DMD could automatically invoke the VC linker?
Re: D1 D2 alpha's for Win64
On 10/14/2012 6:08 PM, Andrej Mitrovic wrote: Ok so we're only supposed to compile with -c when using -m64? I don't suppose DMD could automatically invoke the VC linker? It does automatically invoke the VC linker. You'll need to set the VCINSTALLDIR environment variable. I set it with sc.ini as: - [Environment] LIB=c:\cbx\mars\phobos;c:\cbx\mars\druntime\lib;c:\dm\lib\;c:\curl\lib DDFLAGS=-Ic:\cbx\mars\phobos DFLAGS=-Ic:\cbx\mars\phobos;c:\cbx\mars\druntime\import #LINKCMD=c:\dm\bin\link.exe VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\ --
Re: Feature request: enum init shouldn't create a new enumeration
On Saturday, 13 October 2012 at 20:25:56 UTC, Jonathan M Davis
wrote:
MyEnum me;
final switch (me) // no init case necessary nor allowed
{
case MyEnum.first: break;
case MyEnum.second: break;
}
}
Think about that for a moment. What happens when that final
switch statement is actually run?
There's a bug in that code, because MyEnum default-initializes to
an invalid value. It's effectively the same as this following
code, where the programmer has failed to initialize MyEnum
variable with a valid value:
enum MyEnum { first, second }
void main()
{
MyEnum me = cast(MyEnum)(-123);
final switch (me)
{
case MyEnum.first: break;
case MyEnum.second: break;
}
}
I think that the final switch statement above should throw an
unrecoverable error. I tested it, and nothing happens. I strongly
disagree with this behavior of the compiler (a bug perhaps?).
And remember, that in many cases, T.init is considered to be
perfectly valid. By allowing a final switch _not_ to have it,
it then becomes easy to forget to add a case for it when you
_need_ to, completely defeating the purpose of the final
switch (to make it so that both you and the compiler know that
all of the possible values are accounted for).
If T.init is considered to be perfectly valid, then it means,
that a synonym for it exists among the enumerations. E.g:
enum MyEnum { init = 1, first = 1, second = 42 }
enum ThyEnum { first, second }
In both of those cases, T.first is the synonym of T.init, which
is what both of those enums default-initialize to. Therefore, if
T.init is a valid value, and thus has a synonym among the
enumerations of T, then you can't add a case for init in a final
switch:
MyEnum me;
final switch (me)
{
MyEnum.first: break;
MyEnum.second: break;
MyEnum.init: // Error: duplicate case cast(MyEnum)1
// in switch statement
}
So, this situation you describe, where you *need* to add a case
for init in a final switch, it doesn't exist. T.init should
always either 1) have a synonym among the enumerations or 2)
represent an invalid value.
Re: Is flags enum needed in Phobos?
On Sunday, 7 October 2012 at 09:48:50 UTC, Era Scarecrow wrote:
On Sunday, 7 October 2012 at 09:22:17 UTC, Denis Shelomovskij
wrote:
I'd like to see enum syntax for flug enum. So I dislike
function calls like `set_flag`, `checkAll`, etc. (IMHO)
You mean... binary basic syntax? That shouldn't be too hard.
So something like..?
Flags x;
with(Flags) {
x += one; //setflag
x -= two; //clearflag
x ^= four;//flipflag
x += [one,two]; //set flags multiple, same with flipping and
clearing
x -= [one,two];
x ^= [one,two];
I've added binary functionality. Looking at these notes I see I
forgot the enum/array part; And checking for binary true isn't
added yet. However I'll get to it sooner or later. Both opBinary
and opOpBinary are supported so far.
x += one; //setflag
x -= two; //clearflag
x ^= four;//flipflag
x = two; //keeponly
x |= two; //setFlag, same as +=
//should work fine, as with all operations, const/immutable
safe.
Flags y = x + one;
if (x){} //compile error, will fix later
if (x != Flags()){} //should work, compare against .init
(probably 0)
if (x.state){} //works but you shouldn't depend on this
Re: Feature request: enum init shouldn't create a new enumeration
On Sunday, October 14, 2012 08:20:40 Tommi wrote: There's a bug in that code, because MyEnum default-initializes to an invalid value. It's effectively the same as this following code, where the programmer has failed to initialize MyEnum variable with a valid value: Valid or not, MyEnum.init is still a value for MyEnum and _must_ be accounted for. Trying to treat MyEnum.init as not being a value of MyEnum is likely to break all kinds of stuff. Being able to have a variable of an enum type with a value which is not really a member of the enum is just plain broken. And honestly, declaring a specific init value for an enum is a stupid idea. It's going to screw with all kinds of stuff. Anything assuming that the init property is the first value (is it is in _all_ other cases but isn't necessarily if you declare your own) will be broken. It's still going to end up being in stuff like std.traits.EnumMembers or pretty much anything which operates on enums unless all kinds of special casing is added. TDPL does mention (p. 275) that you can declare enum members with the names max, min, and init, but it also points out that it's a dumb idea. I'd argue that it shouldn't even be legal at all. It's just begging for trouble. - Jonathan M Davis
Re: Feature request: enum init shouldn't create a new enumeration
On Sunday, 14 October 2012 at 06:51:48 UTC, Jonathan M Davis wrote: And honestly, declaring a specific init value for an enum is a stupid idea. I think that declaring a specific *valid* init value for an enum has no purpose. But declaring a specific *invalid* init value, to which the enum initializes to by default, is a very good idea. The reason for why it's a good idea, is exactly the same as why default-initializing floating point variables to NaN is a good idea. Others have reasoned about that enough, thus I don't have to. On Sunday, 14 October 2012 at 06:51:48 UTC, Jonathan M Davis wrote: ... It's going to screw with all kinds of stuff. True, it would break code.
Re: Recommened way to iterate on a narrow string
On Sunday, October 14, 2012 10:07:22 monarch_dodra wrote:
I'm just wondering what the recommended and most efficient
way to do that is?
front + popFront is suboptimal, because you have to evaluate the
code point length twice.
Some sort of fancy stride or decode scheme?
Or can I just go ahead and use foreach, knowing that it is both
easy to use, and super efficient?
If you're just outright iterating over a string and operating on each element
individually, then I see no reason not to use foreach. Just remember to make
the variable dchar:
foreach(dchar c; str) {...}
I don't think that you're going to get more efficient than that unless what
you're doing would work operating on code units instead of code points, but in
that case, iterating probably wouldn't be what you'd want to do anyway. Where
it gets more interesting is where you're doing things more complicated than
simply iterating and operating on each code point individually. Then what the
most efficient thing is depends on what you're doing and functions like stride
and decode can come into play.
- Jonathan M Davis
Why splitter() doesn't work?
Why doesn't code like this work? chain(repeat(a).take(5), repeat(b).take(5)).splitter(b);
Re: RFC: Pinning interface for the GC
On 10/13/2012 8:58 PM, Alex Rønne Petersen wrote: Hi, With precise garbage collection coming up, and most likely compacting garbage collection in the future, I think it's time we start thinking about an API to pin garbage collector-managed objects. A typical approach that people use to 'pin' objects today is to allocate a chunk of memory from the C heap, add it as a root [range], and store a reference in it. That, or just global variables. I guess people don't think about pinning because the GC is not moving objects ;-) As of today, you usually add a root to a garbage collected memory object to keep it in memory (and it can be scanned precisely), but you add a range to a memory chunk not managed by the garbage collector for scanning (you can't pass type info for this, so it is scanned conservatively). So this discussion is about addRoot/removeRoot, not addRange/removeRange (at least in the terminology of the current gc implementation). This is kind of terrible because adding the chunk of memory as a root forces the GC to actually scan it, which is unnecessary when what you really want is to pin the object in place and tell the GC I know what I'm doing, don't touch this. I propose the following functions in core.memory.GC: static bool pin(const(void)* p) nothrow; static bool unpin(const(void)* p) nothrow; The pin function shall pin the object pointed to by p in place such that it is not allowed to be moved nor collected until unpinned. The function shall return true if the object was successfully pinned or false if the object was already pinned or didn't belong to the garbage collector in the first place. The unpin function shall unpin the object pointed to by p such that it is once again eligible for moving and collection as usual. The function shall return true if the object was successfully unpinned or false if the object was not pinned or didn't belong to the garbage collector in the first place. Destroy! Your proposal splits the addRoot-functionality of holding reference, scanning and moving a garbage-collected object into two functions addRoot/pin. For a non-moving garbage collector, this is not really an issue. Adding a root means that there is a reference to the object somewhere outside the reach of the garbage collector, so moving it would make that reference invalid. Not scanning the root object could cause referenced memory chunks to be collected, making the root object invalid. So I think the addRoot functionality should not change, tearing it apart could create invalid references. The pin/unpin functions do make sense for a moving garbage collector, but your motivation above is misleading. It is not related to adding roots or ranges, though I guess using roots is the safer way. Well, thinking about it again, what's the use case of pinning without an external reference and keeping the object alive, just as addRoot would do? Another question, which also affects addRoot/addRange: should there be a pin/unpin counter, so that an object that is pinned twice also needs to be unpinned twice to be movable again? This cannot be implemented by the simple NO_MOVE flag mentioned by David. roots and ranges implement it, but in a slightly inefficient way because the memory is scanned multiple times then.
Making TypeInfo.next() return a const(TypeInfo) was a bad idea
Because you are now no longer able to do stuff like this:
void log(...)
{
auto t = _arguments[0];
while(some condition)
{
t = t.next();
}
}
To be actually able to use TypeInfo.next you will now need the ConstRef
(hack) from phobos. Afaik there is no such thing in druntime which makes
working with TypeInfo.next within druntime a real pita.
Any suggestions?
Kind Regards
Benjamin Thaut
Re: toStringz for UTF-16
On 2012-10-13 15:45, Andrej Mitrovic wrote: This was already proposed before, but it would break too much code. Anyway there's nothing wrong in having an alias that makes typing simpler, e.g. toUTF16z vs toUTF!(const(wchar)*). Phobos has many helper auto functions which make instantiating templates simpler, toUTF16z has that same kind of role. Fair enough. -- /Jacob Carlborg
Re: #pragma comment (lib, ...)
On 2012-10-13 23:11, Jesse Phillips wrote:
Source code does not depend on an import path, that is an environment
issue. Thus you would not specify import paths in source files.
You need to specify it somewhere. Why would I want half of the compiler
flags in one place and the other half in another place? And why should I
need to specify it in the first place, when the built tool can do that
with the help of the package manager.
module bob;
extern(C) void fishingBob();
This function has no definition, code importing bob is not getting
fishingBob.
module joe;
void runningJoe() { ... }
The code importing joe does get runningJoe. So while I think this change
makes sense:
module bob;
pragma(lib, bob.lib);
extern(C) void fishingBob();
This one does not:
module joe;
pragma(lib, joe.lib);
void runningJoe() { ... }
Or
import tango.Text;
pragma(lib, tango.lib); ...
Sure that's not point if you building from source. But if you
pre-compile a library and have import files (.di) then pragma(lib) would
make sense, but it doesn't currently work with import files anyway.
--
/Jacob Carlborg
Re: core.simd woes
On Tuesday, 9 October 2012 at 08:13:39 UTC, Manu wrote: DMD doesn't support non-x86 platforms... What DMD offer's is fine, since it all needs to be collated anyway; GDC/LDC don't agree on intrinsics either. By the way, I just committed a patch to auto-generate GCC-LLVM intrinsic mappings to LDC – thanks, Jernej! –, which would mean that you could in theory use the GDC code path for LDC as well. David
More purity in Rust
They are doing something similar to D on this: http://smallcultfollowing.com/babysteps/blog/2012/10/12/extending-the-definition-of-purity-in-rust/ Bye, bearophile
Re: core.simd woes
On 10/8/2012 4:52 PM, David Nadlinger wrote: With all due respect to Walter, core.simd isn't really designed much at all, or at least this isn't visible in its current state – it rather seems like a quick hack to get some basic SIMD code working with DMD (but beware of ICEs). That is correct. I have little experience with SIMD on x86, and none on other platforms. I'm not in a good position to do a portable and useful design. I was mainly interested in providing a very low level method for a more useful design that could be layered over it. Walter, if you are following this thread, do you have any plans for SIMD on non-x86 platforms? I'm going to leave that up to those who are doing non-x86 platforms for now.
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 09:50:20 UTC, Mehrdad wrote: Why doesn't code like this work? chain(repeat(a).take(5), repeat(b).take(5)).splitter(b); There's two versions of splitter, the version that splits a range using an element, and a version that splits a range using another range. The chain you're using creates a range of strings, and you are splitting it using a string, so it appears you are going for the first version. The signature for that version is: auto splitter(Range, Separator)(Range r, Separator s) if (is(typeof(ElementType!Range.init == Separator.init)) (hasSlicing!Range || isNarrowString!Range)) chain doesn't support slicing (and isn't a narrow string), so you can't split it using this function.
Re: Tips for debugging EXC_BAD_ACCESS
On 2012-10-11 20:19, Michel Fortin wrote: Most likely, the object objc_msgSend is called on has been deallocated, which would mean that windowSendEvent is called with a deallocated NSWindow object as its first argument. I found the problem now, it's really embarrassing. I had missed passing the argument of any super call taking one argument: https://github.com/d-widget-toolkit/dwt-mac/commit/d6674c1074e8a58600cb5052a79b784ae0d3b366 -- /Jacob Carlborg
Re: core.simd woes
David Nadlinger wrote: By the way, I just committed a patch to auto-generate GCC-LLVM intrinsic mappings to LDC – thanks, Jernej! –, which would mean that you could in theory use the GDC code path for LDC as well. Your awesome, David!
Re: Feature request: enum init shouldn't create a new enumeration
On Sun, 14 Oct 2012 09:16:28 +0200 Tommi tommitiss...@hotmail.com wrote: On Sunday, 14 October 2012 at 06:51:48 UTC, Jonathan M Davis wrote: And honestly, declaring a specific init value for an enum is a stupid idea. I think that declaring a specific *valid* init value for an enum has no purpose. But declaring a specific *invalid* init value, to which the enum initializes to by default, is a very good idea. The reason for why it's a good idea, is exactly the same as why default-initializing floating point variables to NaN is a good idea. Others have reasoned about that enough, thus I don't have to. Yes, but it still has to be taken into account in things like final switch. You can't just pretend that nothing will ever have that value, because by making it the init value, you've *made* it an actual possible value, one that just happens to indicate uninitialized.
Re: core.simd woes
On Sunday, 14 October 2012 at 19:40:08 UTC, F i L wrote: David Nadlinger wrote: By the way, I just committed a patch to auto-generate GCC-LLVM intrinsic mappings to LDC – thanks, Jernej! –, which would mean that you could in theory use the GDC code path for LDC as well. Your awesome, David! Usually, yes, but in this case even I must admit that it was jerro who did the work… :P David
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 19:26:37 UTC, Peter Alexander wrote: On Sunday, 14 October 2012 at 09:50:20 UTC, Mehrdad wrote: Why doesn't code like this work? chain(repeat(a).take(5), repeat(b).take(5)).splitter(b); There's two versions of splitter, the version that splits a range using an element, and a version that splits a range using another range. The chain you're using creates a range of strings, and you are splitting it using a string, so it appears you are going for the first version. The signature for that version is: auto splitter(Range, Separator)(Range r, Separator s) if (is(typeof(ElementType!Range.init == Separator.init)) (hasSlicing!Range || isNarrowString!Range)) chain doesn't support slicing (and isn't a narrow string), so you can't split it using this function. Yup, but why does it need slicing?
Re: core.simd woes
On Sunday, 7 October 2012 at 12:24:48 UTC, Manu wrote: Perfect! I can get on with my unittests :P Speaking of test – are they available somewhere? Now that LDC at least theoretically supports most of the GCC builtins, I'd like to throw some tests at it to see what happens. David
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 20:03:52 UTC, Mehrdad wrote: On Sunday, 14 October 2012 at 19:26:37 UTC, Peter Alexander wrote: On Sunday, 14 October 2012 at 09:50:20 UTC, Mehrdad wrote: Why doesn't code like this work? chain(repeat(a).take(5), repeat(b).take(5)).splitter(b); chain doesn't support slicing (and isn't a narrow string), so you can't split it using this function. Yup, but why does it need slicing? Well, for example: splitter(hello world, ' ') gives [hello, world] The splits are slices of the original range. splitter could allocate new ranges, but if you want that behaviour then it's better to specify it manually: chain(repeat(a).take(5), repeat(b).take(5)).array().splitter(b); That works, giving: [[a, a, a, a, a], [], [], [], [], []] I wonder if a better design for splitter would automatically allocate an array when the input range doesn't support slicing?
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 20:09:44 UTC, Peter Alexander wrote: Well, for example: splitter(hello world, ' ') gives [hello, world] The splits are slices of the original range. splitter could allocate new ranges, but if you want that behaviour then it's better to specify it manually: chain(repeat(a).take(5), repeat(b).take(5)).array().splitter(b); That works, giving: [[a, a, a, a, a], [], [], [], [], []] I wonder if a better design for splitter would automatically allocate an array when the input range doesn't support slicing? Oh I didn't realize that, it's because it wants to slice the original range... Yeah, I think that might not be such a bad idea. It should be possible to slice infinite ranges too, after all.
Re: core.simd woes
On 14 October 2012 21:05, David Nadlinger s...@klickverbot.at wrote: On Sunday, 7 October 2012 at 12:24:48 UTC, Manu wrote: Perfect! I can get on with my unittests :P Speaking of test – are they available somewhere? Now that LDC at least theoretically supports most of the GCC builtins, I'd like to throw some tests at it to see what happens. David Could you pastebin a header generation of the gccbuiltins module? We can compare. =) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Tips for debugging EXC_BAD_ACCESS
On 2012-10-14 19:38:21 +, Jacob Carlborg d...@me.com said: On 2012-10-11 20:19, Michel Fortin wrote: Most likely, the object objc_msgSend is called on has been deallocated, which would mean that windowSendEvent is called with a deallocated NSWindow object as its first argument. I found the problem now, it's really embarrassing. I had missed passing the argument of any super call taking one argument: https://github.com/d-widget-toolkit/dwt-mac/commit/d6674c1074e8a58600cb5052a79b784ae0d3b366 By the way, that line is half-fishy: super_struct.super_class = cast(objc.Class) OS.objc_msgSend(id, OS.sel_superclass); It'll work as long as you have only one level of derived classes, and only as long as you don't have a class that overrides the superclass method (which would be weird, I acknowledge). You should be aware of this if you're creating new object classes, especially the first part (the second part is only relevant if you wish to implement some kind of proxy objects). Theoretically, I think it'd be better to use directly functions from the Objective-C runtime[1], which also avoids the dynamic dispatch overhead of objc_msgSend: super_struct.super_class = class_getSuperclass(object_getClass(id)); Note however that this is still not equivalent to calling: [super method:arg0]; because this last one gets the class pointer at compile-tome from its static symbol, so there's no overhead at all (and it works with derived classes of derived classes too). [1]: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: core.simd woes
On 14 October 2012 21:58, Iain Buclaw ibuc...@ubuntu.com wrote: On 14 October 2012 21:05, David Nadlinger s...@klickverbot.at wrote: On Sunday, 7 October 2012 at 12:24:48 UTC, Manu wrote: Perfect! I can get on with my unittests :P Speaking of test – are they available somewhere? Now that LDC at least theoretically supports most of the GCC builtins, I'd like to throw some tests at it to see what happens. David Could you pastebin a header generation of the gccbuiltins module? We can compare. =) http://dpaste.dzfl.pl/4edb9ecc -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
OPTLINK is missing files when I try to include debugging info into build
I was trying to check out windbg with a project I am working on. The program currently consists of two D files (main.d, Application.d) and three Derelict3 import libs (DerelictUtil, DerelictSDL2, DerelictGL3). Without debug info, the following console command runs fine; --- dmd main.d Application.d DerelictUtil.lib DerelictSDL2.lib DerelictGL3.lib --- However, no matter where I put either the -g or -gc switches, Optlink complains with 'Error 118: Filename Expected', and proceeds to spit out my PATH environment variable. I tried with just a 'Hello World' program that only imports 'std.stdio', and I get the same problem. Could anyone explain to me what the problem is? I have the feeling that there is something I need to do to set up Optlink, however I installed from the Windows binary on dlang.org. If it matters, I'm running Win7
Re: OPTLINK is missing files when I try to include debugging info into build
On 10/15/12, Matt webwra...@fastmail.fm wrote: However, no matter where I put either the -g or -gc switches, Optlink complains with 'Error 118: Filename Expected Likely related to this: http://d.puremagic.com/issues/show_bug.cgi?id=8791
Re: Why splitter() doesn't work?
On Sunday, October 14, 2012 22:13:28 Mehrdad wrote: Yeah, I think that might not be such a bad idea. It should be possible to slice infinite ranges too, after all. There's actually some discussion on making it so that you can't. The main problem is that a slice can't be the same type as the original for an infinite range, which tends to screw with things. But if infinite ranges end up losing the ability to be sliced, then other, similar functionality would have to be added, because you _do_ need to be able to take chunks of an infinite range like that. - Jonathan M Davis
Re: OPTLINK is missing files when I try to include debugging info into build
On Sunday, 14 October 2012 at 22:53:11 UTC, Andrej Mitrovic wrote: On 10/15/12, Matt webwra...@fastmail.fm wrote: However, no matter where I put either the -g or -gc switches, Optlink complains with 'Error 118: Filename Expected Likely related to this: http://d.puremagic.com/issues/show_bug.cgi?id=8791 OK, so it's a bug rather than a failure on my part? That's comforting, if a little problematic.
Re: Why splitter() doesn't work?
On Sunday, October 14, 2012 22:09:43 Peter Alexander wrote: I wonder if a better design for splitter would automatically allocate an array when the input range doesn't support slicing? We generally try and avoid any kind of allocation like that in std.algorithm. We leave it up to the programmer to do that. Otherwise, you'd end up with all kinds of invisible performance hits. And it's doubly bad for anyone trying to avoid using the GC. - Jonathan M Davis
Re: OPTLINK is missing files when I try to include debugging info into build
On 10/15/12, Matt webwra...@fastmail.fm wrote: On Sunday, 14 October 2012 at 22:53:11 UTC, Andrej Mitrovic wrote: On 10/15/12, Matt webwra...@fastmail.fm wrote: However, no matter where I put either the -g or -gc switches, Optlink complains with 'Error 118: Filename Expected Likely related to this: http://d.puremagic.com/issues/show_bug.cgi?id=8791 OK, so it's a bug rather than a failure on my part? That's comforting, if a little problematic. Likely. What does your PATH variable look like?
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 22:58:27 UTC, Jonathan M Davis wrote: On Sunday, October 14, 2012 22:13:28 Mehrdad wrote: Yeah, I think that might not be such a bad idea. It should be possible to slice infinite ranges too, after all. There's actually some discussion on making it so that you can't. The main problem is that a slice can't be the same type as the original for an infinite range, which tends to screw with things. But if infinite ranges end up losing the ability to be sliced, then other, similar functionality would have to be added, because you _do_ need to be able to take chunks of an infinite range like that. - Jonathan M Davis How are you supposed to split a range that doesn't support slicing though? You can't just call array() because it might be too big to be reasonable for fitting it into memory...
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 23:01:02 UTC, Jonathan M Davis wrote: On Sunday, October 14, 2012 22:09:43 Peter Alexander wrote: I wonder if a better design for splitter would automatically allocate an array when the input range doesn't support slicing? We generally try and avoid any kind of allocation like that in std.algorithm. We leave it up to the programmer to do that. Otherwise, you'd end up with all kinds of invisible performance hits. And it's doubly bad for anyone trying to avoid using the GC. - Jonathan M Davis Well, you don't need to automatically allocate anything. As long as you require the input to be a forward range, you can simply iterate over it over and over again every time you want to return front(). AFAICT no need to store anything anywhere.
Re: Why splitter() doesn't work?
On Sunday, 14 October 2012 at 23:11:32 UTC, Mehrdad wrote: How are you supposed to split a range that doesn't support slicing though? You can't just call array() because it might be too big to be reasonable for fitting it into memory... (Canonical example: splitting a stream by newlines)
Re: Why splitter() doesn't work?
On Monday, October 15, 2012 01:11:28 Mehrdad wrote: How are you supposed to split a range that doesn't support slicing though? You can't just call array() because it might be too big to be reasonable for fitting it into memory... If you're splitting on an element, slicing isn't necessary. It's only splitting on a range that requires slicing. However, because splitter is lazy, I would think that it would be perfectly possible to define it such that it didn't need slicing. It would still need a forward range (for the same reason that find requires forward ranges if it's not looking for a single element), but I would think that you could define it with just forward ranges. Worst case, the result would have to be a range over Take!Range rather than over slices of Range, and that's basically what infinite ranges have to do when slicing anyway. So, unless I'm missing something, I think that splitter is currently being overly restrictive in its implementation. - Jonathan M Davis
Re: OPTLINK is missing files when I try to include debugging info into build
On Sunday, 14 October 2012 at 23:06:19 UTC, Andrej Mitrovic wrote: On 10/15/12, Matt webwra...@fastmail.fm wrote: On Sunday, 14 October 2012 at 22:53:11 UTC, Andrej Mitrovic wrote: On 10/15/12, Matt webwra...@fastmail.fm wrote: However, no matter where I put either the -g or -gc switches, Optlink complains with 'Error 118: Filename Expected Likely related to this: http://d.puremagic.com/issues/show_bug.cgi?id=8791 OK, so it's a bug rather than a failure on my part? That's comforting, if a little problematic. Likely. What does your PATH variable look like? Horrific. It's full of paths to sub-directories of C:\Program Files\. I've found that if I run set PATH=C:\D\dmd2\windows\bin before compiling, it works fine. If it usually takes time for this, I'll just set up a cmd shell with this reduced PATH envvar, I think.
Re: core.simd woes
Speaking of test – are they available somewhere? Now that LDC at least theoretically supports most of the GCC builtins, I'd like to throw some tests at it to see what happens. David I have a fork of std.simd with LDC support at https://github.com/jerro/phobos/tree/std.simd and some tests for it at https://github.com/jerro/std.simd-tests .
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On 14-10-2012 12:19, Benjamin Thaut wrote:
Because you are now no longer able to do stuff like this:
void log(...)
{
auto t = _arguments[0];
while(some condition)
{
t = t.next();
}
}
To be actually able to use TypeInfo.next you will now need the ConstRef
(hack) from phobos. Afaik there is no such thing in druntime which makes
working with TypeInfo.next within druntime a real pita.
Any suggestions?
Kind Regards
Benjamin Thaut
None, to be honest. I can only recommend going with a cast hack or
something similar for now.
But this is a problem we *must* solve. It is something I also ran into
often while hacking on druntime.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Is flags enum needed in Phobos?
On Sunday, 14 October 2012 at 06:34:39 UTC, Era Scarecrow wrote: I've added binary functionality. Looking at these notes I see I forgot the enum/array part; And checking for binary true isn't added yet. However I'll get to it sooner or later. Both opBinary and opOpBinary are supported so far. I can't get opOpAssign working properly, and it's worse with arrays. Removing opOpAssign, everything else (arrays, single flags, other flags) works properly. It's likely the last time I'll update it for a while. And I guess that's it.
Re: Is flags enum needed in Phobos?
Era Scarecrow: I can't get opOpAssign working properly, and it's worse with arrays. Removing opOpAssign, everything else (arrays, single flags, other flags) works properly. Are such problems known? In bugzilla or here? Are those fixable? It's likely the last time I'll update it for a while. And I guess that's it. Are you going to create a Phobos GitHugHub pull request? Bye, bearophile
D seems interesting, but...
Hello All,
I have been looking at D off and on for several years. Initially
I worked through a very painful experience to get D compiling on
Linux. After that experience, I concluded that I should wait for
it to become more mature. Since then, I do a very simple test. I
install the latest package and try to build Hello World. I
figure that if Hello World builds successfully, I will continue
further. I have just downloaded the latest .deb package and
installed it on Ubuntu 12.04 32bit. Once again it fails this
incredibly simple test. I've read many discussions about how/why,
has/hasn't, will/won't D hit the mainstream in programming
languages. I think this situation may offer at least one data
point. I'm struggling to think of any other language (and I use
several) that won't build code out of the box. D seems to have a
lot of potential, but this needs to be fixed. I am not asking for
help on this. I honestly don't care what the solution is. I just
wanted the D developers to know why at least one developer is not
using the language. I sincerely hope that the situation will
improve. I'm looking forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In
function `_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In
function `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In
function `thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined
reference to `_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined
reference to `_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In
function `thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined
reference to `_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined
reference to `_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
Re: Is flags enum needed in Phobos?
On Monday, 15 October 2012 at 02:54:38 UTC, bearophile wrote: Era Scarecrow: I can't get opOpAssign working properly, and it's worse with arrays. Removing opOpAssign, everything else (arrays, single flags, other flags) works properly. Are such problems known? In bugzilla or here? Are those fixable? mmm... As I'm looking at it and making a reply, I've noticed a couple mistakes. Give me an hour or so to test and add it in. If all's well it will be fixed/added Are you going to create a Phobos GitHugHub pull request? Wasn't planning on it. If you feel the library is good enough, I may add a request. But more likely it will be merged with another file, likely std.bitmanip or something...
Re: D seems interesting, but...
On 15-10-2012 05:10, Gerry Weaver wrote:
Hello All,
I have been looking at D off and on for several years. Initially I
worked through a very painful experience to get D compiling on Linux.
After that experience, I concluded that I should wait for it to become
more mature. Since then, I do a very simple test. I install the latest
package and try to build Hello World. I figure that if Hello World
builds successfully, I will continue further. I have just downloaded the
latest .deb package and installed it on Ubuntu 12.04 32bit. Once again
it fails this incredibly simple test. I've read many discussions about
how/why, has/hasn't, will/won't D hit the mainstream in programming
languages. I think this situation may offer at least one data point. I'm
struggling to think of any other language (and I use several) that won't
build code out of the box. D seems to have a lot of potential, but this
needs to be fixed. I am not asking for help on this. I honestly don't
care what the solution is. I just wanted the D developers to know why at
least one developer is not using the language. I sincerely hope that the
situation will improve. I'm looking forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
I really don't know what to tell you, because:
$ dmd -m32 test.d
$ dmd -m64 test.d
$ cat test.d
import std.stdio;
void main()
{
writeln(Hello, world!);
}
It Works For Me (TM).
What package (URL please) did you install?
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
On 15-10-2012 06:31, Gerry Weaver wrote:
On Monday, 15 October 2012 at 04:20:04 UTC, Alex Rønne Petersen wrote:
On 15-10-2012 05:10, Gerry Weaver wrote:
Hello All,
I have been looking at D off and on for several years. Initially I
worked through a very painful experience to get D compiling on Linux.
After that experience, I concluded that I should wait for it to become
more mature. Since then, I do a very simple test. I install the latest
package and try to build Hello World. I figure that if Hello World
builds successfully, I will continue further. I have just downloaded the
latest .deb package and installed it on Ubuntu 12.04 32bit. Once again
it fails this incredibly simple test. I've read many discussions about
how/why, has/hasn't, will/won't D hit the mainstream in programming
languages. I think this situation may offer at least one data point. I'm
struggling to think of any other language (and I use several) that won't
build code out of the box. D seems to have a lot of potential, but this
needs to be fixed. I am not asking for help on this. I honestly don't
care what the solution is. I just wanted the D developers to know why at
least one developer is not using the language. I sincerely hope that the
situation will improve. I'm looking forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
I really don't know what to tell you, because:
$ dmd -m32 test.d
$ dmd -m64 test.d
$ cat test.d
import std.stdio;
void main()
{
writeln(Hello, world!);
}
It Works For Me (TM).
What package (URL please) did you install?
Hi,
I downloaded the package from dlang.org. The package was
dmd_2.060-0_i386.deb. The install went fine. I have to admit that I was
surprised there were issues this time around.
Thanks,
-G
Would you happen to have an i386 Ubuntu system I could SSH into and have
a look or something? I'm on amd64 over here which works OK with the
amd64 package on dlang.org.
I suspect we generally have a relatively low 32-bit Linux user base
these days...
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
On Monday, 15 October 2012 at 04:20:04 UTC, Alex Rønne Petersen
wrote:
On 15-10-2012 05:10, Gerry Weaver wrote:
Hello All,
I have been looking at D off and on for several years.
Initially I
worked through a very painful experience to get D compiling on
Linux.
After that experience, I concluded that I should wait for it
to become
more mature. Since then, I do a very simple test. I install
the latest
package and try to build Hello World. I figure that if
Hello World
builds successfully, I will continue further. I have just
downloaded the
latest .deb package and installed it on Ubuntu 12.04 32bit.
Once again
it fails this incredibly simple test. I've read many
discussions about
how/why, has/hasn't, will/won't D hit the mainstream in
programming
languages. I think this situation may offer at least one data
point. I'm
struggling to think of any other language (and I use several)
that won't
build code out of the box. D seems to have a lot of potential,
but this
needs to be fixed. I am not asking for help on this. I
honestly don't
care what the solution is. I just wanted the D developers to
know why at
least one developer is not using the language. I sincerely
hope that the
situation will improve. I'm looking forward to programming in
D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In
function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In
function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined
reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined
reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In
function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In
function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined
reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined
reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
I really don't know what to tell you, because:
$ dmd -m32 test.d
$ dmd -m64 test.d
$ cat test.d
import std.stdio;
void main()
{
writeln(Hello, world!);
}
It Works For Me (TM).
What package (URL please) did you install?
Hi,
I downloaded the package from dlang.org. The package was
dmd_2.060-0_i386.deb. The install went fine. I have to admit that
I was surprised there were issues this time around.
Thanks,
-G
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex Rønne Petersen wrote:
On 15-10-2012 05:10, Gerry Weaver wrote:
[...]
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
This looks like what happens if you try to use the latest dmd release
with an old version of Phobos, perhaps installed along with gdc.
Whoever's doing the .deb packaging really should add a versioned
Depends: field to debian/control so that it will require installation of
the correct version of Phobos, or, at the very least, refuse to install
if such is not available.
[...]
I really don't know what to tell you, because:
$ dmd -m32 test.d
$ dmd -m64 test.d
$ cat test.d
import std.stdio;
void main()
{
writeln(Hello, world!);
}
It Works For Me (TM).
What package (URL please) did you install?
[...]
Yeah, if it's an outdated package, then it's kinda moot. (Though we
really should remove outdated packages where we can, they can kinda
become a fly in the soup sometimes.)
T
--
Tell me and I forget. Teach me and I remember. Involve me and I
understand. -- Benjamin Franklin
Re: D seems interesting, but...
On Sunday, October 14, 2012 21:39:42 H. S. Teoh wrote: This looks like what happens if you try to use the latest dmd release with an old version of Phobos, perhaps installed along with gdc. Whoever's doing the .deb packaging really should add a versioned Depends: field to debian/control so that it will require installation of the correct version of Phobos, or, at the very least, refuse to install if such is not available. At this point, it's a bad idea to use any version of druntime or Phobos which doesn't match exactly with the version of dmd that you're using. It's not as bad as it used to be, but there are still plenty of cases where a language change (be it a bug fix or added feature or whatever) makes it so that older versions of Phobos won't compile, or the latest Phobos ends up needing the latest dmd. I wouldn't advise anyone to use versions of them that don't all match. - Jonathan M Davis
Re: D seems interesting, but...
On 15-10-2012 06:39, H. S. Teoh wrote:
On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex Rønne Petersen wrote:
On 15-10-2012 05:10, Gerry Weaver wrote:
[...]
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
This looks like what happens if you try to use the latest dmd release
with an old version of Phobos, perhaps installed along with gdc.
Whoever's doing the .deb packaging really should add a versioned
Depends: field to debian/control so that it will require installation of
the correct version of Phobos, or, at the very least, refuse to install
if such is not available.
The thing about the DMD packages for Debian/Ubuntu is that they install
DMD, Phobos/druntime, all D headers, and tools like rdmd and dman in one
package.
[...]
I really don't know what to tell you, because:
$ dmd -m32 test.d
$ dmd -m64 test.d
$ cat test.d
import std.stdio;
void main()
{
writeln(Hello, world!);
}
It Works For Me (TM).
What package (URL please) did you install?
[...]
Yeah, if it's an outdated package, then it's kinda moot. (Though we
really should remove outdated packages where we can, they can kinda
become a fly in the soup sometimes.)
T
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
On Monday, 15 October 2012 at 04:34:10 UTC, Alex Rønne Petersen
wrote:
On 15-10-2012 06:31, Gerry Weaver wrote:
On Monday, 15 October 2012 at 04:20:04 UTC, Alex Rønne
Petersen wrote:
On 15-10-2012 05:10, Gerry Weaver wrote:
Hello All,
I have been looking at D off and on for several years.
Initially I
worked through a very painful experience to get D compiling
on Linux.
After that experience, I concluded that I should wait for it
to become
more mature. Since then, I do a very simple test. I install
the latest
package and try to build Hello World. I figure that if
Hello World
builds successfully, I will continue further. I have just
downloaded the
latest .deb package and installed it on Ubuntu 12.04 32bit.
Once again
it fails this incredibly simple test. I've read many
discussions about
how/why, has/hasn't, will/won't D hit the mainstream in
programming
languages. I think this situation may offer at least one
data point. I'm
struggling to think of any other language (and I use
several) that won't
build code out of the box. D seems to have a lot of
potential, but this
needs to be fixed. I am not asking for help on this. I
honestly don't
care what the solution is. I just wanted the D developers to
know why at
least one developer is not using the language. I sincerely
hope that the
situation will improve. I'm looking forward to programming
in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In
function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In
function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined
reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined
reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In
function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In
function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined
reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined
reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
I really don't know what to tell you, because:
$ dmd -m32 test.d
$ dmd -m64 test.d
$ cat test.d
import std.stdio;
void main()
{
writeln(Hello, world!);
}
It Works For Me (TM).
What package (URL please) did you install?
Hi,
I downloaded the package from dlang.org. The package was
dmd_2.060-0_i386.deb. The install went fine. I have to admit
that I was
surprised there were issues this time around.
Thanks,
-G
Would you happen to have an i386 Ubuntu system I could SSH into
and have a look or something? I'm on amd64 over here which
works OK with the amd64 package on dlang.org.
I suspect we generally have a relatively low 32-bit Linux user
base these days...
Hi,
Unfortunately, I don't. This is a special dev system I setup for
a customer project. They have several 32bit only apps that force
the 32bit requirement. Actually, I would be using D on 64bit
anyway. I just happened to be working on this particular system
when I
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 06:45:16AM +0200, Gerry Weaver wrote: [...] Unfortunately, I don't. This is a special dev system I setup for a customer project. They have several 32bit only apps that force the 32bit requirement. Actually, I would be using D on 64bit anyway. I just happened to be working on this particular system when I decided to check out the latest D package. I will try the 64bit package. In the mean time, I would be more than happy to gather any information that would help. [...] Hmm. I just tested it on a 32-bit Debian system, using the package from the exact URL you gave, and I didn't see any problems. So I'm wondering if somehow dmd is picking up the wrong version of Phobos somehow, maybe a stale copy somewhere? Maybe a stale /etc/dmd.conf that pointed to the wrong version of the library? (Debian/Ubuntu packages generally do not overwrite modified configuration files upon installation -- so if there is an old dmd.conf there that has been modified in the past, it will have stayed unchanged when you installed the new dmd. Check if there's a file called /etc/dmd.conf.dpkg-new; if there is, rename it to /etc/dmd.conf and see if that fixes the problem.) T -- The richest man is not he who has the most, but he who needs the least.
Re: D seems interesting, but...
On Sun, Oct 14, 2012 at 09:42:56PM -0700, Jonathan M Davis wrote: On Sunday, October 14, 2012 21:39:42 H. S. Teoh wrote: This looks like what happens if you try to use the latest dmd release with an old version of Phobos, perhaps installed along with gdc. Whoever's doing the .deb packaging really should add a versioned Depends: field to debian/control so that it will require installation of the correct version of Phobos, or, at the very least, refuse to install if such is not available. At this point, it's a bad idea to use any version of druntime or Phobos which doesn't match exactly with the version of dmd that you're using. It's not as bad as it used to be, but there are still plenty of cases where a language change (be it a bug fix or added feature or whatever) makes it so that older versions of Phobos won't compile, or the latest Phobos ends up needing the latest dmd. I wouldn't advise anyone to use versions of them that don't all match. [...] Hmm, I just checked the URL he gave, and the package there includes the entire suite: dmd, druntime, phobos, all in one. The only potential problem I can think of is that /etc/dmd.conf had been modified in the past and the Debian/Ubuntu packaging system doesn't overwrite modified conffiles upon upgrade, so dmd may be picking up the wrong version of druntime/Phobos because of that. Another potential problem I can think of, is that the package is missing a Depends: on one of the system libraries, maybe pthread-related, judging from the error messages? Specifically, one needs to depend on the -dev version of the library, as non-dev versions of Debian/Ubuntu library packages may only contain .so files, not the other stuff (headers, .a's, etc.) that may be necessary to link to the library. One way to root out this problem is to create a bare-bones chroot environment (cf. dbootstrap) that has the absolute minimum packages installed, and see if the package installs and runs correctly there. Quite often, dependencies are missed because the library depended on is commonly installed on most systems, but isn't part of the base system, so on rare occasions the library will be missing and the package will install correctly but fail to work. T -- Don't modify spaghetti code unless you can eat the consequences.
Re: D seems interesting, but...
On Monday, 15 October 2012 at 05:05:17 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 06:45:16AM +0200, Gerry Weaver wrote: [...] Unfortunately, I don't. This is a special dev system I setup for a customer project. They have several 32bit only apps that force the 32bit requirement. Actually, I would be using D on 64bit anyway. I just happened to be working on this particular system when I decided to check out the latest D package. I will try the 64bit package. In the mean time, I would be more than happy to gather any information that would help. [...] Hmm. I just tested it on a 32-bit Debian system, using the package from the exact URL you gave, and I didn't see any problems. So I'm wondering if somehow dmd is picking up the wrong version of Phobos somehow, maybe a stale copy somewhere? Maybe a stale /etc/dmd.conf that pointed to the wrong version of the library? (Debian/Ubuntu packages generally do not overwrite modified configuration files upon installation -- so if there is an old dmd.conf there that has been modified in the past, it will have stayed unchanged when you installed the new dmd. Check if there's a file called /etc/dmd.conf.dpkg-new; if there is, rename it to /etc/dmd.conf and see if that fixes the problem.) T Hi, I checked it out. There is only a dmd.conf. I've included it below. ; ; dmd.conf file for dmd ; ; dmd will look for dmd.conf in the following sequence of directories: ; - current working directory ; - directory specified by the HOME environment variable ; - directory dmd resides in ; - /etc directory ; ; Names enclosed by %% are searched for in the existing environment and inserted ; ; The special name %@P% is replaced with the path to this file ; [Environment] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib /i386-linux-gnu -L-L/usr/lib/x86_64-linux-gnu -L--no-warn-search-mismatch -L--ex port-dynamic Thanks, -G
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote: [...] Hi, I checked it out. There is only a dmd.conf. I've included it below. [...] Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T -- If creativity is stifled by rigid discipline, then it is not true creativity.
Re: D seems interesting, but...
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote: [...] Hi, I checked it out. There is only a dmd.conf. I've included it below. [...] Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T Hi, Here's what I've got. Package: libc6 Multi-Arch: same Priority: required Section: libs Installed-Size: 9125 Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com Architecture: i386 Source: eglibc Version: 2.15-0ubuntu10.2 Replaces: belocs-locales-bin, libc6-i386 Provides: glibc-2.13-1, libc6-i686 Depends: libc-bin (= 2.15-0ubuntu10.2), libgcc1, tzdata Suggests: glibc-doc, debconf | debconf-2.0, locales Breaks: libhwloc0, liblouis0 ( 2.3.0-2), liblouisxml1 ( 2.4.0-2), nscd ( 2.15) Conflicts: belocs-locales-bin, libc6-i686, prelink ( 0.0.20090925), tzdata ( 2007k-1), tzdata-etch Filename: pool/main/e/eglibc/libc6_2.15-0ubuntu10_i386.deb Size: 3934936 MD5sum: 941333dcbfcc262636b89e6e387ebe18 Description: Embedded GNU C Library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others. Homepage: http://www.eglibc.org Original-Maintainer: GNU Libc Maintainers debian-gl...@lists.debian.org Thanks, -G
Re: Is flags enum needed in Phobos?
K I have opOpAssign working. I may have to clean up documentation a little and clean the unittests up a bit, but it all appears to be working. Feel free to give it a try. I have added opSlice, which returns an array of your enum of all the flags it qualifies for. An empty enum (say, zero) never qualifies as it has no bits to make it unique (or it would always be present no matter what). Mmm... I actually hope that's all that's needed for it.
Porting unit tests
I recently noticed that the SWT repository contains unit tests. I think it would be create if these tests could be ported and included into DWT. The tests are located in the tests directory in the SWT git repository: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests?id=v3449 The address of the git repository is: http://git.eclipse.org/gitroot/platform/eclipse.platform.swt.git We're using release 3.449.0, with the corresponding git tag v3449. -- /Jacob Carlborg
Re: Operator overloading through UFCS doesn't work
On Saturday, 13 October 2012 at 22:34:19 UTC, H. S. Teoh wrote: OK, before this thread devolves into a shouting match, I'd like to understand what was the rationale behind this restriction. What were the reasons behind not allowing a non-member function to overload an operator? What are the pros and cons considered at the time, and how do they weigh now? Or was it just a matter of not being implemented because nobody thought about it at the time? T It likely was not implemented rather than disallowed. The only mentioned reason is to allow writing operator overloading methods outside type scope - just because somebody (currently two people) consider it logical to broaden UFCS usage. This doesn't solve ay practical issue.
Re: Operator overloading through UFCS doesn't work
On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote: Another way to describe my reasoning... According to TDPL, if var is a variable of a user-defined type, then: ++var gets rewritten as: var.opUnary!++() Not always. If user-defined type has an alias this to integer member, than something different would happen. It would be also interesting to see, how operation ++T would differ because somebody imported module with opUnary method. Because opUnary suits better than alias this, dmd will issue call to that function, it it see its declaration.
COM Example work for anyone?
The dmd compiler comes with some example code. One of the examples is for COM. Does this work for anyone else? The dll registration code is failing: SetKeyAndValue() failed. Other output looks good: OLE 2 initialized hMod = 268435456 LoadLibraryA() succeeded pfn = 100033E0, fn = 'DllRegisterServer' dmd -ofdserver .\dserver.d .\chello.d .\dserver.def dmd .\dclient.d .\chello.d I also added a couple pragma's to the files to help with linking pragma(lib, advapi32.lib); pragma(lib, ole32.lib); pragma(lib, oleaut32.lib); pragma(lib, ole32.lib);
Re: Operator overloading through UFCS doesn't work
On Sunday, 14 October 2012 at 06:22:03 UTC, Maxim Fomin wrote: On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote: Another way to describe my reasoning... According to TDPL, if var is a variable of a user-defined type, then: ++var gets rewritten as: var.opUnary!++() Not always. If user-defined type has an alias this to integer member, than something different would happen. Yeah, I wasn't specific enough with that example. It would be also interesting to see, how operation ++T would differ because somebody imported module with opUnary method. Because opUnary suits better than alias this, dmd will issue call to that function, it it see its declaration. Actually, it seems that alias this has precedence over UFCS. So, a free function opUnary wouldn't ever suit better than an actual method opUnary of the thing referred to by that alias this.
Re: Operator overloading through UFCS doesn't work
On Saturday, 13 October 2012 at 19:50:02 UTC, Timon Gehr wrote: On 10/13/2012 06:02 PM, Maxim Fomin wrote: ... Different groups of people have different mind and same things produce different sense on them. From my point of view operator overloading methods are special functions and not treating them as candidates for UFCS does make more sense. I do not understand how an operation that happens to be called '+' is fundamentally different from an operation that is called 'add'. The first one is an operator, which sometimes, may be rewritten to function call, the second one is a function call. Even if you convince in your opinion, language addition without applied purposes makes no benefit. I guess the functionality could be achieved in DMD mostly by removing code. (Code for good error messages excluded!) I don't understand what you are trying to say. Anyway, you can write a pull request and propose it at github. It would be interesting to see reaction of others.
Re: Operator overloading through UFCS doesn't work
On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote: Actually, it seems that alias this has precedence over UFCS. So, a free function opUnary wouldn't ever suit better than an actual method opUnary of the thing referred to by that alias this. http://dpaste.dzfl.pl/d0a4431d Free function doesn't suit better than actual method. The issue is absence of the actual method. opUnary method has priority over alias this, which does make sense because alias this is chosen only when it is impossible to apply operation over A type. If this request is approved and compiler has opUnary definition outside type (which suits better then alias this) such function would hijack alias this. If not, there is a new case when something is going special than at usual cases and only for the purpose of writing operator overloading methods outside the body of the type.
Re: equivalent of c++ private inheritance with using
On Friday, 12 October 2012 at 23:05:27 UTC, Jonathan M Davis
wrote:
You can have the variable be private and alias a function which
returns by ref
instead of the variable itself. Something like
class C
{
@property ref inout(Impl) get() inout { return _impl; }
alias get this;
private:
Impl _impl;
}
- Jonathan M Davis
Thanks, that is interesting, but is it the same? I don't think
that this then provides any encapsulation? The idea is the client
gets no access to Impl methods unless I say so and I say so with
a using declaration. Then you can introduce more functionality,
so it is implementation inheritance. It might not be possible to
get the exact same thing, since the RateCurve struct is not
really Array!DateValue, it just looks like it with the alias. The
closest I can get is to alias each of what is needed and add
forwarding functions. So, for example, with this new RateCurve,
clients can call insert() but not call clear().
struct RateCurve {
alias Array!DateRate ContainerType;
alias ContainerType.Range Range;
alias _impl this;
size_t insert(Stuff)(Stuff stuff) {
enforce(_impl.empty || (stuff.when = _impl.back.when),
text(Can not insert items out of order ,
_impl.back, is newer than , stuff));
return _impl.insert(stuff);
}
DateRate getRate(Date asOf) {
auto needle = DateRate(asOf, 0);
if(!_impl.empty) {
auto sortedRage = assumeSorted!(a.when = b.when,
Range)(opSlice());
auto lowerBound = sortedRage.lowerBound(needle);
if(!lowerBound.empty) {
needle = lowerBound.back;
}
}
return needle;
}
Range opSlice() { return _impl.opSlice(); }
this(U)(U[] values...) if (isImplicitlyConvertible!(U,
DateRate)) {
foreach (value; values) {
insert(value);
}
}
private:
ContainerType _impl;
}
What am I doing wrong here?
Hey everyone, I'm new to D so bare with me please. I've been
trying to figure out what's up with the strange forward refernce
errors the compiler (DMD 2.060) is giving me. Here's a code
snippet that's generating a forward reference error:
public class AliasTestClass(alias func)
{
static assert(__traits(isStaticFunction, func));
}
public class TestClass
{
private AliasTestClass!(randomFunction) test; // -
public static void randomFunction()
{
}
}
The strange part about it is that if I surround the
randomFunction parameter with another pair of paranthesis like so
private AliasTestClass!((randomFunction)) test;
It works just fine. If I don't, however, I get a forward
reference error:
Error: template instance main.AliasTestClass!(randomFunction)
forward reference of randomFunction
Am I doing anything wrong or is this some kind of bug?
Re: What am I doing wrong here?
On 2012-10-14, 14:28, Martin wrote:
Hey everyone, I'm new to D so bare with me please. I've been trying to
figure out what's up with the strange forward refernce errors the
compiler (DMD 2.060) is giving me. Here's a code snippet that's
generating a forward reference error:
public class AliasTestClass(alias func)
{
static assert(__traits(isStaticFunction, func));
}
public class TestClass
{
private AliasTestClass!(randomFunction) test; // -
public static void randomFunction()
{
}
}
The strange part about it is that if I surround the randomFunction
parameter with another pair of paranthesis like so
private AliasTestClass!((randomFunction)) test;
It works just fine. If I don't, however, I get a forward reference error:
Error: template instance main.AliasTestClass!(randomFunction) forward
reference of randomFunction
Am I doing anything wrong or is this some kind of bug?
It's a bug. Maybe it's already in Bugzilla (there are some forward-ref
bugs there already). Please file:
http://d.puremagic.com/issues/enter_bug.cgi
--
Simen
Re: What am I doing wrong here?
On Sunday, 14 October 2012 at 12:58:24 UTC, Simen Kjaeraas wrote:
On 2012-10-14, 14:28, Martin wrote:
Hey everyone, I'm new to D so bare with me please. I've been
trying to figure out what's up with the strange forward
refernce errors the compiler (DMD 2.060) is giving me. Here's
a code snippet that's generating a forward reference error:
public class AliasTestClass(alias func)
{
static assert(__traits(isStaticFunction, func));
}
public class TestClass
{
private AliasTestClass!(randomFunction) test; // -
public static void randomFunction()
{
}
}
The strange part about it is that if I surround the
randomFunction parameter with another pair of paranthesis like
so
private AliasTestClass!((randomFunction)) test;
It works just fine. If I don't, however, I get a forward
reference error:
Error: template instance main.AliasTestClass!(randomFunction)
forward reference of randomFunction
Am I doing anything wrong or is this some kind of bug?
It's a bug. Maybe it's already in Bugzilla (there are some
forward-ref
bugs there already). Please file:
http://d.puremagic.com/issues/enter_bug.cgi
Oh, thank you for clarifying, I thought I was doing something
wrong :)
Re: Ignoring defaults from sc.ini?
On 10/14/12, Benjamin Thaut c...@benjamin-thaut.de wrote: Is there a way to make dmd ignore the default imports and library search paths inside sc.ini? See http://dlang.org/dmd-windows.html#sc_ini
Re: How many std.concurrency receivers?
On Oct 12, 2012, at 2:29 AM, Russel Winder rus...@winder.org.uk wrote: On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote: […] I'm not clear on what Fibers are. From Ruby they seem to mean co-routines, and that doesn't have much advantage. But it also seems as […] I think the emerging consensus is that threads allow for pre-emptive scheduling whereas fibres do not. So yes as in Ruby, fibres are collaborative co-routines. Stackless Python is similar. Yep. If fibers were used in std.concurrency there would basically be an implicit yield in send and receive.
Re: How many std.concurrency receivers?
On 14-Oct-12 20:19, Sean Kelly wrote: On Oct 12, 2012, at 2:29 AM, Russel Winder rus...@winder.org.uk wrote: On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote: […] I'm not clear on what Fibers are. From Ruby they seem to mean co-routines, and that doesn't have much advantage. But it also seems as […] I think the emerging consensus is that threads allow for pre-emptive scheduling whereas fibres do not. So yes as in Ruby, fibres are collaborative co-routines. Stackless Python is similar. Yep. If fibers were used in std.concurrency there would basically be an implicit yield in send and receive. Makes me wonder how it will work with blocking I/O and the like. If all of (few of) threads get blocked this way that going to stall all of (thousands of) fibers. -- Dmitry Olshansky
Re: Ignoring defaults from sc.ini?
On Sunday, 14 October 2012 at 09:40:36 UTC, Benjamin Thaut wrote: Is there a way to make dmd ignore the default imports and library search paths inside sc.ini? Currently I have to keep two versions of dmd around, one with a modified sc.ini and one with the original one, which is a bit annoying. A command line option for the compiler to ignore the defaults inside sc.ini would be really great. You might want to have a look at DVM: https://bitbucket.org/doob/dvm/wiki/Home -- /Jacob Carlborg
Re: COM Example work for anyone?
I haven't tried to run it, but as a random guess, does the user your running it as have permissions to write to HKEY_CLASSES_ROOT ?
Re: Operator overloading through UFCS doesn't work
On 10/14/12 08:13, Maxim Fomin wrote: The only mentioned reason is to allow writing operator overloading methods outside type scope - just because somebody (currently two people) consider it logical to broaden UFCS usage. It's more than two people... Also, it's not about broadening UFCS usage, it's about making UFCS work properly. This doesn't solve ay practical issue. Obviously, it does. Otherwise this issue wouldn't come up repeatedly. artur
Re: Operator overloading through UFCS doesn't work
On Sunday, 14 October 2012 at 07:14:25 UTC, Maxim Fomin wrote:
If this request is approved and compiler has opUnary definition
outside type (which suits better then alias
this) such function would hijack alias this.
Free functions cannot and must not ever hijack, i.e. modify
existing functionality of a type. Free functions should only be
able to add new functionality to a type. This is what currently
happens with alias this vs free function which is accessed
through UFCS:
struct B
{
void fun()
{
writeln(B.fun());
}
}
struct A
{
B b;
alias b this;
}
void fun(A a)
{
writeln(.fun(A));
}
void main()
{
A a;
a.fun(); // prints B.fun() as it should
}
It shouldn't be any different if fun was some operator function,
like opUnary; the free function mustn't hijack type A's existing
functionality (which is currently being provided to A by that
alias this thingy).
Re: COM Example work for anyone?
On Sunday, 14 October 2012 at 19:04:22 UTC, Richard Webb wrote: I haven't tried to run it, but as a random guess, does the user your running it as have permissions to write to HKEY_CLASSES_ROOT ? Guess that would be it. Specifically told the program to run as admin and it works. Should have checked if you left a message here first, but GitHub is better about telling me new messages. My comserver branch's example also has the registration through manifest which I'm not getting to work. Wonder if it is the same issue... This should at least get me started building customer servers such that I can build a much better understanding of how these all fit together and test what works vs what is an environment issue. But I'm getting a little tired for now so I'll probably look at some other aspects for a bit. Thanks for watching my work and helping.
Re: toStringz note about keeping references
On Sunday, October 14, 2012 23:38:48 Andrej Mitrovic wrote: toStringz takes a string (immutable(char)[]), and the GC will not reclaim immutable data until app exit. If the GC never collects immutable data which has no references to it until the app closes, then there's a serious problem. Immutability shouldn't factor into that at all. Anything and everything with no references to it any longer should be up for collection. Any other behavior would effectively result in huge memory leaks - especially if you're doing a lot with strings. Maybe you're seeing the behavior that you're seeing because the GC mistakingly thinks that something points to it (as happens sometimes - especially in 32- bit programs). - Jonathan M Davis
Re: toStringz note about keeping references
On Monday, October 15, 2012 00:51:34 Andrej Mitrovic wrote: On 10/15/12, Jonathan M Davis jmdavisp...@gmx.com wrote: Anything and everything with no references to it any longer should be up for collection. I think this is fuzzy territory and it's a good opportunity to properly document GC behavior. I don't see how it could be fuzzy at all. It makes no sense whatsoever to keep _any_ data around once it has nothing referencing it. The constness of an object should have _zero_ affect on its scope or lifetime. immutable _does_ implicitly make a variable shared, but that has nothing to do with the object's lifetime. That just makes it so that it can be used across threads. Once no more threads reference it, it should collected. Keeping the data around would simply result in the effective equivalent of leaked memory. For example, TDPL states that immutable data is always available, and that a user should treat such data as if it existed throughout the lifetime of the program. I'd have to see exactly what TDPL says to comment on that accurately, but if it means that all immutable data is expected to be around for the entire lifetime of the program, then that's a huge problem. If it's something that was specifically allocated in ROM when the program started, then that makes sense (e.g. string literals on Linux), but nothing allocated on the normal GC heap should be kept alive simply because it's immutable. References to it must exist. - Jonathan M Davis
Re: toStringz note about keeping references
On 10/15/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
I'd have to see exactly what TDPL says to comment on that accurately
Maybe I've misread it. On Page 288 it says:
An immutable value is cast in stone: as soon as it's been
initialized, you may as well
consider it has been burned forever into the memory storing it. It
will never change
throughout the execution of the program.
Perhaps what was missing is: as long as there is a reference to that data.
I'd really like to know for sure if the GC implementation actually
collects immutable data or not. I've always used toStringz in direct
calls to C without caring about keeping a reference to the source
string in D code. I'm sure others have used it like this as well.
Maybe the only reason my apps which use C don't crash is because a GC
cycle doesn't often run, and when it does run it doesn't collect the
source string data (either on purpose or because of buggy behavior, or
because the GC is imprecise).
Anyway this stuff is important for OOP wrappers of C/C++ libraries. If
the string reference must kept on the D side then this makes writing
wrappers harder. For example, let's say you've had this type of
wrapper:
extern(C) void* get_Foo_obj();
extern(C) void* c_Foo_test(void* c_obj, const(char)* input);
class Foo
{
this() { c_Foo_obj = get_Foo_obj(); } // init c object by calling
a C function
void test(string input)
{
c_Foo_test(c_Foo_obj, toStringz(input));
}
void* c_Foo_obj; // reference to C object
}
Should we always store a reference to 'input' to avoid GC collection? E.g.:
class Foo
{
this() { c_Foo_obj = get_Foo_obj(); } // init c object by calling
a C function
void test(string input)
{
input_ref = input
c_Foo_test(c_Foo_obj, toStringz(input));
}
string input_ref; // keep it alive, C might use it after test() returns
void* c_Foo_obj; // reference to C object
}
And what about multiple calls? What if on each call to c_Foo_test()
the C library stores each 'input' pointer internally? That would mean
we have to keep an array of these pointers on the D side.
It's not know what the C library does without inspecting the source of
the C library. So it becomes very difficult to write wrappers which
are GC-safe.
There are wrappers out there that seem to expect the source won't be
collected. For example GtkD also uses toStringz in calls to C without
ever storing a reference to the input string.
Re: toStringz note about keeping references
On 10/14/2012 04:36 PM, Andrej Mitrovic wrote:
On 10/15/12, Jonathan M Davisjmdavisp...@gmx.com wrote:
I'd have to see exactly what TDPL says to comment on that accurately
Maybe I've misread it. On Page 288 it says:
An immutable value is cast in stone: as soon as it's been
initialized, you may as well
consider it has been burned forever into the memory storing it. It
will never change
throughout the execution of the program.
Perhaps what was missing is: as long as there is a reference to that
data.
Andrei must have written that only D in mind, without any C interaction.
When we consider only D, then the statement is correct: If there is no
more references, how can the application tell that the data is gone or not?
I'd really like to know for sure if the GC implementation actually
collects immutable data or not.
It does. Should be easy to test with an infinite loop that generates
immutable data.
I've always used toStringz in direct
calls to C without caring about keeping a reference to the source
string in D code. I'm sure others have used it like this as well.
It depends on whether the C-side keeps a copy of that pointer.
Maybe the only reason my apps which use C don't crash is because a GC
cycle doesn't often run, and when it does run it doesn't collect the
source string data (either on purpose or because of buggy behavior, or
because the GC is imprecise).
Anyway this stuff is important for OOP wrappers of C/C++ libraries. If
the string reference must kept on the D side then this makes writing
wrappers harder. For example, let's say you've had this type of
wrapper:
extern(C) void* get_Foo_obj();
extern(C) void* c_Foo_test(void* c_obj, const(char)* input);
class Foo
{
this() { c_Foo_obj = get_Foo_obj(); } // init c object by calling
a C function
void test(string input)
{
c_Foo_test(c_Foo_obj, toStringz(input));
}
void* c_Foo_obj; // reference to C object
}
Should we always store a reference to 'input' to avoid GC collection?
If the C function copies the pointer, yes.
E.g.:
class Foo
{
this() { c_Foo_obj = get_Foo_obj(); } // init c object by calling
a C function
void test(string input)
{
input_ref = input
c_Foo_test(c_Foo_obj, toStringz(input));
}
string input_ref; // keep it alive, C might use it after test()
returns
That's exactly what I do in a C++ library that wraps C types.
void* c_Foo_obj; // reference to C object
}
And what about multiple calls? What if on each call to c_Foo_test()
the C library stores each 'input' pointer internally? That would mean
we have to keep an array of these pointers on the D side.
Again, that's exactly what I do in C++. :) There is a global container
that keeps the objects alive.
It's not know what the C library does without inspecting the source of
the C library. So it becomes very difficult to write wrappers which
are GC-safe.
Most functions document what they do with the input parameters. If not,
it is usually obvious.
There are wrappers out there that seem to expect the source won't be
collected. For example GtkD also uses toStringz in calls to C without
ever storing a reference to the input string.
Must be verified case-by-case.
Ali
Re: toStringz note about keeping references
On Monday, October 15, 2012 01:36:27 Andrej Mitrovic wrote: On 10/15/12, Jonathan M Davis jmdavisp...@gmx.com wrote: I'd have to see exactly what TDPL says to comment on that accurately Maybe I've misread it. On Page 288 it says: An immutable value is cast in stone: as soon as it's been initialized, you may as well consider it has been burned forever into the memory storing it. It will never change throughout the execution of the program. Perhaps what was missing is: as long as there is a reference to that data. That says _nothing_ about collection. It's only saying that the value won't ever change. It's trying to highlight the difference between const and immutable. It would make _no_ sense for immutable data to not be collected when all references to it were gone. I'd really like to know for sure if the GC implementation actually collects immutable data or not. I guarantee that if it doesn't, it's a bug. There are exceptions (e.g. string literals in Linux - because they go in ROM), and the GC isn't exactly enthusiastic about reclaiming memory, which means that stuff can hang around for quite a while, but normally, immutability should have no effect on the lifetime of an object. I've always used toStringz in direct calls to C without caring about keeping a reference to the source string in D code. It's perfectly safe as long as the C function doesn't hold on to the pointer. If it does, then you could get screwed later on when that pointer gets used, and whether it works or not then becomes non-deterministic (since it depends on whether the GC has collected the memory or not and whether that memory has been reused) which could cause some really nasty bugs. That's why the note on toStringz is there in the first place. It would not surprise me at all if it's a common bug when interfacing with C that references are not kept around when they should be. I suspect that the main reason that it doesn't cause more issues is because most C functions don't keep pointers around. Anyway this stuff is important for OOP wrappers of C/C++ libraries. If the string reference must kept on the D side then this makes writing wrappers harder. That's true, but to some extent, that's just life when dealing with interfacing with code outside of the GC's reach. However, I believe that another option is to explicitly tell the GC not collect a chunk of memory (glancing at core.memory, I suspect that removeRoot is the function to use for that, but I've never done it before, so I'm not well acquainted with the details). But if you want it to ever be collected, you'd need to make sure that it was readded to the GC again later, which could also complicate wrappers. It _is_ another option though if keeping a reference around in the D code is problematic. And what about multiple calls? What if on each call to c_Foo_test() the C library stores each 'input' pointer internally? That would mean we have to keep an array of these pointers on the D side. Potentially, yes. It's not know what the C library does without inspecting the source of the C library. So it becomes very difficult to write wrappers which are GC-safe. Unfortunately, that's true. However, remember that in C, you normally have to manage your own memory, so if C functions aren't appropriately clear about who owns what memory or which pointers get kept, then they'll run into serious problems in pure C. So, in general, I would expect a C function to be fairly clear when it keeps a pointer around or gives you a pointer to memory that it allocated or controls. But it's fairly rare that C functions keep pointers around (that would mean using global variables which are generally rare), so in most cases, it's a non-issue. There are wrappers out there that seem to expect the source won't be collected. For example GtkD also uses toStringz in calls to C without ever storing a reference to the input string. As long as the function doesn't keep any of the pointers that it's given, then it's fine. If it _does_ keep a pointer around, then it's a bug for the D code not to keep a reference around. But as I said, it's fairly rare for C code to do that, which is probably why this doesn't cause more issues. But the note on toStringz is there precisely because most people aren't going to think of that problem, and they need to be aware of it when using toStringz. - Jonathan M Davis
Re: toStringz note about keeping references
On 10/15/12, Jonathan M Davis jmdavisp...@gmx.com wrote: snip Hmm ok, this sheds some light on things. If a C function takes a const pointer and has no documentation about ownership then maybe it's a good guess to say it won't store that pointer anywhere and will only use it as a temporary?
Re: toStringz note about keeping references
On Monday, October 15, 2012 02:04:44 Andrej Mitrovic wrote: On 10/15/12, Jonathan M Davis jmdavisp...@gmx.com wrote: snip Hmm ok, this sheds some light on things. If a C function takes a const pointer and has no documentation about ownership then maybe it's a good guess to say it won't store that pointer anywhere and will only use it as a temporary? Generally speaking yes. It's rare for them to keep pointers around, and if they do and don't tell you, then they're creating bugs in C code too. Most C functions (especially if you're talking OS functions) which keep memory that you pass to them or give you memory thaty you didn't pass to them will inform you about it in their documentation. - Jonathan M Davis
Re: How many std.concurrency receivers?
On Oct 14, 2012, at 9:59 AM, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 14-Oct-12 20:19, Sean Kelly wrote: On Oct 12, 2012, at 2:29 AM, Russel Winder rus...@winder.org.uk wrote: On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote: […] I'm not clear on what Fibers are. From Ruby they seem to mean co-routines, and that doesn't have much advantage. But it also seems as […] I think the emerging consensus is that threads allow for pre-emptive scheduling whereas fibres do not. So yes as in Ruby, fibres are collaborative co-routines. Stackless Python is similar. Yep. If fibers were used in std.concurrency there would basically be an implicit yield in send and receive. Makes me wonder how it will work with blocking I/O and the like. If all of (few of) threads get blocked this way that going to stall all of (thousands of) fibers. Ideally, IO would be nonblocking with a yield there too, at least if the operation would block.
Re: To: Johannes Pfau
On 10/15/12 02:14, Andrej Mitrovic wrote: Johannes, are you still working on gobject introspection? libgit has gobject bindings so I remembered you mentioning something about working on gobject for D. FWIW gobject bindings are part of my gtk2 bindings too; http://repo.or.cz/w/girtod.git/blob/refs/heads/gtk2:/gtk2/gobject2.d artur
Re: std.stream, BOM, and deprecation
On Sat, 13 Oct 2012 18:53:48 -0700 Charles Hixson charleshi...@earthlink.net wrote: If std.stream is being deprecated, what is the correct way to deal with file BOMs. This is particularly concerning utf8 files, which I understand to be a bit problematic, as there isn't, actually, a utf8 BOM, merely a convention which isn't a part of a standard. But the std.stdio documentation doesn't so much as mention byte order marks (BOMs). If this should wait until std.io is released, then I could use std.stream until them, but the documentation is already warning to avoid using it. Personally, I think it's kind of cumbersome to deal with in Phobos, so I wrote this wrapper that I use instead, which handles everything: https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/io.d?at=master#cl-24 And then there's the utfConvert below it if you already have the data in memory instead of on disk. (Maybe I should add some range capability and make a Phobos pull request. I don't know if it'd fly though. It uses a lot of custom endian- and bom-related code since I found the existing endian/bom stuff in phobos inadequate. So that stuff would have to be accepted, and then this too, and it's usually a bit of a pain to get things approved.)
Specifying precision in %(...%) print format
I have an array of reals that I want to format with writefln, but the precision field needs to be passed in a variable. For a single real, it would be writefln(%.*f, precision, x); but when I try this: int precision = ...; real[] array = ...; writefln(%(%.*f, %), precision, array); I get a runtime exception with the message integral. I assume that's because %(%) is expecting an array, but sees an int, so it fails. But swapping the order of parameters doesn't help either: writefln(%(%.*f, %), array, precision); produces floating point format failure. What's the right way to do this? T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Re: Specifying precision in %(...%) print format
On 10/14/2012 10:43 PM, H. S. Teoh wrote:
I have an array of reals that I want to format with writefln, but the
precision field needs to be passed in a variable. For a single real, it
would be writefln(%.*f, precision, x); but when I try this:
int precision = ...;
real[] array = ...;
writefln(%(%.*f, %), precision, array);
I get a runtime exception with the message integral. I assume that's
because %(%) is expecting an array, but sees an int, so it fails. But
swapping the order of parameters doesn't help either:
writefln(%(%.*f, %), array, precision);
produces floating point format failure.
What's the right way to do this?
T
Here is a way with format:
import std.stdio;
import std.string;
void main()
{
int precision = 2;
real[] array = [ 1.234 ];
writefln(format(%%(%%.%sf, %%), precision), array);
}
Ali
[Issue 8816] New: It should be illegal for enums to declare members named init, max, or min
http://d.puremagic.com/issues/show_bug.cgi?id=8816
Summary: It should be illegal for enums to declare members
named init, max, or min
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-13 23:57:05
PDT ---
TDPL (p.275) specifically allows for enums to declare members named min, max,
and init and then immediately tells you that it's a dumb idea to do so.
Allowing it is bound to break generic code, since it allows you to do nonsense
like
enum MyEnum : int {max, min, init}
completely breaking any guarantees about what the mean. And note this fun
situation:
enum MyEnum : int { a, b, c, init }
void main()
{
MyEnum e;
assert(e == MyEnum.a);
assert(MyEnum.init == MyEnum.a);
}
The first assertion passes and the second fails, meaning that the declartion of
init has effectively hidden the real init. I'd strongly argue that allowing the
overloading init, min, and max should be disallowed. Allowing it gains us
nothing and just causes bugs.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8817] New: Symbols named init should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=8817
Summary: Symbols named init should be illegal
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 00:04:46
PDT ---
The fact that the compiler currently allows any symbols to be named init just
causes problems. For instance, take this program:
struct S
{
int i = 2;
this(int j)
{
assert(i == 2);
i = j;
}
@property static init()
{
return S(5);
}
}
void main()
{
assert(S.init == S(2));
}
The assertion in main fails, while the assertion in the constructor succeeds.
That means that it's failing to actually override the init property for S
(which is good), but now the init property for S is inaccessible. This is
dangerous and will break all kinds of code. This sort of thing should just be
disallowed. It gains us nothing and just causes problems. Similarly, this code
struct S
{
int i = 2;
this(int j)
{
assert(i == 2);
i = j;
}
@property S init()
{
return S(5);
}
}
void main()
{
assert(S.init == S(2));
}
results in this compilation error:
q.d(19): Error: need 'this' for init type @property S()
So, again, it makes it impossible to access the type's init property.
For some reason, TDPL (p. 275) specifically permits enums to declare min, max,
and init properties, though it _does_ tell you that it's a bad idea to do so.
So, if that's to be permitted, init would still have to be allowed there, but
I'd strongly argue that that should be changed. And note that just like with
structs, it causes weird issues:
enum MyEnum : int { a, b, c, init }
void main()
{
MyEnum e;
assert(e == MyEnum.a);
assert(MyEnum.init == MyEnum.a);
}
The first assertion passes but the second fails, meaning that once again, you
can't get at the init property of the type anymore. Sure, declaring init as the
first value fixes that, but init would be the first value anyway if init
weren't explicitly declared. See issue# 8816.
The only situation where explicitly declaring init might make some sense would
be to @disable it, but the syntax for disabling init is @disable this(); and
not anything directly involving init. You can try and declare
struct S
{
int i;
@disable static S init;
}
void main()
{
S s;
}
but it compiles just fine.
At minimum, I would strongly argue that any and all symbols which could
conflict with the actual init property for a type should be made illegal. There
are a few cases where it may not cause problems (e.g. a local variable), but
I'd argue that it would be cleaner to just disallow those as well. If need be,
maybe init should become a keyword. Certainly, the current situation just
permits bugs and the ability to declare symbols named init which conflict with
the actual init property for a type needs to be eliminated.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8816] It should be illegal for enums to declare members named init, max, or min
http://d.puremagic.com/issues/show_bug.cgi?id=8816 --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 00:05:18 PDT --- See also issue# 8817. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8816] It should be illegal for enums to declare members named init, max, or min
http://d.puremagic.com/issues/show_bug.cgi?id=8816 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-14 09:36:24 CEST --- For what it's worth, I agree that it's nonsensical to even allow this. It's just inviting catastrophe. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8817] Symbols named init should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=8817 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-14 09:38:30 CEST --- This actually happens to be a problem in druntime's TypeInfo classes because they have a property called init. A lot of code currently relies on that 'overload' of the init symbol. https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L75 That comment has been there for eons. What do we do about it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8817] Symbols named init should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=8817 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-14 00:48:24 PDT --- That comment has been there for eons. What do we do about it? Create a function with the correct name (whatever that is - initialize?) and mark the old one as scheduled for deprecation making sure that we put an appropriate note in the changelog (in red if we think that it's major enough - I don't know how much code really uses TypeInfo, let alone TypeInfo.init() though). Then we deprecate it. It'll probably have to stick around as deprecated for a while to help the transition, but after that, we remove it, and it won't cause an issues any longer. Unfortunately, it wouldn't surprise me if there are plenty of types out there with an init function (std.file.DirEntry used to have one), but IMHO it's just fundamentally broken to allow that given how it conflicts with the actual init property. And I think that this is a case where it's worth breaking code if we have to (but that makes it that much more critical that we make the changes necessary for this sooner rather than later). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8809] Cannot statically bind to base class method overridden by derived class
http://d.puremagic.com/issues/show_bug.cgi?id=8809 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-10-14 03:02:36 PDT --- https://github.com/D-Programming-Language/dmd/pull/1181 And, this is also a problem in website. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
