Multiple alias this is coming.
I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it.
Re: Multiple alias this is coming.
On 18/09/2014 11:20 p.m., IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Awesome was waiting for something like this! Also did we ever consider alias this = ...; syntax?
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 12:51:48 UTC, Rikki Cattermole wrote: On 18/09/2014 11:20 p.m., IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Awesome was waiting for something like this! Also did we ever consider alias this = ...; syntax? It clashes with (not yet supported) aliasing of constructors.
Re: 438-byte Hello, world Win32 EXE in D
On Thursday, 18 September 2014 at 04:50:52 UTC, dcrepid wrote: On Wednesday, 17 September 2014 at 20:49:37 UTC, Vladimir Panteleev wrote: Yes, sorry, that was the wrong command. Currently you have to also specify the full paths to the compiler on make's command line. I sent in two pull requests to document and simplify building phobos32mscoff.lib: https://github.com/D-Programming-Language/druntime/pull/960 https://github.com/D-Programming-Language/phobos/pull/2526 Thanks, I tried merging the modifications into the 'win32mscoff.mak' files I've made, since it seems like there's too much hacking to get this to work right, and why not just have a 3rd build option that reflects what it really makes? You mean yet another makefile? It's onerous enough already to duplicate all makefile changes across the current set. Yet another makefile for a rarely-used configuration wouldn't pull its own weight. Perhaps this is an issue with the current beta, but I'm not experienced enough with make files or versioning etc to make that determination. It sounds like whatever version you have doesn't yet have the necessary Phobos/Druntime changes. You should try building from the git version.
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 18:38:57 UTC, Ali Çehreli wrote: On 09/18/2014 04:20 AM, IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Awesome! This is the feature that I thought would never get implemented. :) Ali No, these are rvalue references. ;)
Re: Multiple alias this is coming.
IgorStepanov: I've created pull request, which introduces multiple alias this. Can someone show one or more usage cases? Thank you, bye, bearophile
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 19:52:42 UTC, bearophile wrote:
IgorStepanov:
I've created pull request, which introduces multiple alias
this.
Can someone show one or more usage cases?
Thank you,
bye,
bearophile
Do you ask about alias this or about it multiple usage. Multiple
usage is similar to single, but multiple:)
struct Foo
{
string s;
int i;
alias s this;
alias i this;
}
Foo f = {foo, 42};
string s = f; //s == foo
int i = f; //i == 42
If there are many different ways to resolve alias this then error
is raised:
struct Bar
{
double d;
int i;
alias d this;
alias i this;
}
Foo f = {1.0, 42};
double d = f; //Error: compiler doesn't know, f.d or f.i do you
want.
In the next expamle, compiler can resolve conflict:
struct Base1
{
int i;
alias i this;
}
struct Base2
{
int i;
alias i this;
}
struct Derived
{
Base1 b1;
Base2 b2;
int i;
alias b1 this;
alias b2 this;
alias i this;
}
Derived d = Derived(Base1(1), Base2(2), 3);
int i = d; //i == 3;
This done because Derived author know, how to cast his struct to
int, and if he say alias i this; this alias hide aliases in base
types.
However, if base type contains alias this to another acceptable
type, and derived typ hasn't exactly castable alias this then
error will be raised:
struct Base1
{
short s;
alias s this;
}
struct Base2
{
int i;
alias i this;
}
struct Derived
{
Base1 b1;
Base2 b2;
int i;
alias b1 this;
alias b2 this;
alias i this;
}
Derived d = Derived(Base1(1), Base2(2), 3);
int i = d; //Ok i == 3;
long l = d; //Error: what do you want? d.i or d.b1.s?
For additional info you can see examples in my pull request.
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 11:20:49 UTC, IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Exciting! What more good things than a better behaving Nullable(T) with T being a polymorphic class will this enable?
Re: Multiple alias this is coming.
IgorStepanov: Do you ask about alias this or about it multiple usage. Multiple usage is similar to single, but multiple:) I meant the multiple usage. And none of your examples here are use cases :-( I'd like to see one use case, or more. Bye, bearophile
Re: Multiple alias this is coming.
On 09/18/2014 12:52 PM, bearophile wrote:
Can someone show one or more usage cases?
I can't claim that I have experience with multiple alias this ;) but I
like the following example that I had come up with:
class TeachingAssistant
{
Student studentIdentity;
Teacher teacherIdentity;
this(string name, string subject)
{
this.studentIdentity = new Student(name);
this.teacherIdentity = new Teacher(name, subject);
}
/* The following two 'alias this' declarations will enable
* this type to be used both as a Student and as a Teacher. */
alias teacherIdentity this;
alias studentIdentity this;
}
Ali
[1] http://ddili.org/ders/d.en/alias_this.html
Re: Multiple alias this is coming.
On Thu, 18 Sep 2014 15:20:04 -0700 Ali Çehreli via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: [1] http://ddili.org/ders/d.en/alias_this.html heh, i just wanted to point at your book. ;-) signature.asc Description: PGP signature
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 22:16:23 UTC, bearophile wrote:
IgorStepanov:
Do you ask about alias this or about it multiple usage.
Multiple usage is similar to single, but multiple:)
I meant the multiple usage. And none of your examples here are
use cases :-( I'd like to see one use case, or more.
Bye,
bearophile
For example, you can define struct (value-type with automatic
storage class) which implements interfaces:
intarface InputStream
{
...
}
intarface OutputStream
{
...
}
struct File
{
this(string name, string options)
{
impl = new FileImpl(name, options);
}
~this()
{
impl.close();
}
@property InputStream inputStream()
{
return new class(impl) InputStream
{
//InputStream implementation
...
}
}
@property OutputStream outputStream()
{
return new class(impl) OutputStream
{
//OutputStream implementation
...
}
}
alias inputStream this;
alias seekable this;
FileImpl* impl;
}
Record[] readData(InputStream);
void storeData(OutputStream, Record[]);
Record[] extractRecords()
{
File f = File(records.bin, rw);
auto data = readData(f);
///split to extracted and remaining
f.truncate();
writeData(f, remaining);
return extracted;
}
Digger 1.0
Most notable change since DConf is that on Windows, Digger can now build D from source (including x64 versions) without requiring Git or Visual Studio to be installed. It achieves this by downloading and locally installing (unpacking) all the software it needs. Windows binaries: https://github.com/CyberShadow/Digger/releases/tag/1.0 Digger is a tool for working with D's source code and its history. It can build D (including older D versions), customize the build with pending pull requests or forks, and find the exact pull request which introduced a regression (or fixed a bug). It comes together with a web interface which makes building D from source trivial even for people new to D, Git or the command line. https://github.com/CyberShadow/Digger
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 11:20:49 UTC, IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. What is the policy to resolve conflict ? BTW, SDC already have multiple alias this :)
Re: Now, a critic of Stroustrup's choices
Very insightful. Sadly, the allocator question is far from solved. I guess this is an area where D can make a difference.
Re: Now, a critic of Stroustrup's choices
On Wednesday, 17 September 2014 at 12:05:58 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 17 September 2014 at 09:21:13 UTC, eles wrote: These are some notes I have on C++'s operator new. Basically, I find its syntax downright hateful, and really wish the language had dealt more cleanly with allocation and construction. FWIW, Simula had new. C++ is B.S.' attempt to marry C with Simula. It's not designed, but more like translated, then mutilated a posteriori… Hence the hodgepodge syntax (and semantics). Bjarne's book about C++ design and evolution is quite good to understand how C's compatibility and other issues drove C++ design. -- Paulo
Re: Now, a critic of Stroustrup's choices
On Thursday, 18 September 2014 at 08:14:42 UTC, Paulo Pinto wrote: Bjarne's book about C++ design and evolution is quite good to understand how C's compatibility and other issues drove C++ design. I guess cfront affected the design a lot by being based on converting the input to C. Not adding a proper module system was a big mistake, but that is OT.
Re: Now, a critic of Stroustrup's choices
On Thursday, 18 September 2014 at 08:33:53 UTC, Ola Fosheim Grostad wrote: On Thursday, 18 September 2014 at 08:14:42 UTC, Paulo Pinto wrote: Bjarne's book about C++ design and evolution is quite good to understand how C's compatibility and other issues drove C++ design. I guess cfront affected the design a lot by being based on converting the input to C. Not adding a proper module system was a big mistake, but that is OT. These issues are touched in the book if I remember correctly. Quite a few C++ design decisions came from the requirement to fit 1:1 with C toolchains. Now we need to wait for C++17, or do some marketing that D has them today. :) -- Paulo
Re: Example of the perils of binding rvalues to const ref
On Thursday, 18 September 2014 at 00:53:40 UTC, Andrei Alexandrescu wrote: On 9/17/14, 12:28 PM, IgorStepanov wrote: I want to place Foo(1) to buckets[nn].key without postblit call. Compiler can't help me now, however, I think, It can do it without language change. File an enhancement request with explanations and sample code, the works. This will be good. Thanks! -- Andrei I think it's this one: https://issues.dlang.org/show_bug.cgi?id=12684 Kind of required when you requested emplace from rvalues: https://issues.dlang.org/show_bug.cgi?id=12628
Re: Example of the perils of binding rvalues to const ref
On Thursday, 18 September 2014 at 00:53:40 UTC, Andrei Alexandrescu wrote: On 9/17/14, 12:28 PM, IgorStepanov wrote: I want to place Foo(1) to buckets[nn].key without postblit call. Compiler can't help me now, however, I think, It can do it without language change. File an enhancement request with explanations and sample code, the works. This will be good. Thanks! -- Andrei Done: https://issues.dlang.org/show_bug.cgi?id=13492
Re: Example of the perils of binding rvalues to const ref
On Thursday, 18 September 2014 at 10:50:31 UTC, monarch_dodra wrote: On Thursday, 18 September 2014 at 00:53:40 UTC, Andrei Alexandrescu wrote: On 9/17/14, 12:28 PM, IgorStepanov wrote: I want to place Foo(1) to buckets[nn].key without postblit call. Compiler can't help me now, however, I think, It can do it without language change. File an enhancement request with explanations and sample code, the works. This will be good. Thanks! -- Andrei I think it's this one: https://issues.dlang.org/show_bug.cgi?id=12684 Kind of required when you requested emplace from rvalues: https://issues.dlang.org/show_bug.cgi?id=12628 Yes, your 12684 issue is a case of new 13492. I've tried to classify the problem and describe a danger cases.
Re: assume, assert, enforce, @safe
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven Schveighoffer wrote: The cost for this is tremendous. You may as well not use classes. Looks like ldc has a separate option to turn off invariants.
Re: assume, assert, enforce, @safe
On Thu, 18 Sep 2014 08:57:20 -0400, Kagamin s...@here.lot wrote: On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven Schveighoffer wrote: The cost for this is tremendous. You may as well not use classes. Looks like ldc has a separate option to turn off invariants. That's a good thing. I'm actually thinking this should be in DMD as well. invariants, always called by default, when almost no object defines one, is really costly. It's also a virtual call, which means any inlining is not possible. -Steve
Re: Using D
On 06/09/2014 01:50, Paulo Pinto wrote: Am 05.09.2014 23:56, schrieb Dicebot: On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: You can write DLLs in Java, for example with http://www.excelsiorjet.com/. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. Why pick Java if not for JVM? It is mediocre language at most, very limited and poor feature-wise, lacking expressive power even compared to C++ (you can at least abuse templates in the latter). JVM, however, may be the best VM environment implementation out there and that can be useful. Enterprise answer: - lots of libraries to chose from; - lots of easy to find (replacable) programmers; -- Paulo Also, superior development-time tools: IDEs, debuggers. (the debugging support could be considered part of the JVM though, depending on how you look at it.) Also, me and a lot others don't agree Java is a mediocre language. It is basic language, yes. But a lot of good software can be written comfortably with just a basic language. C++ is more *powerful* than Java, but it doesn't mean its better. I would rather be programming in Java over C++, any time. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Using D
On 05/09/2014 14:42, Chris wrote: A jar can only be used by another Java program. Making a Java program accessible to 3rd party software via a DLL is not so simple, and the JVM has to be up and running all the time. Java is cross-platform as long as you stay within the safe and cosy Java bubble that floats on top of the JVM. But once you step outside of the JVM, gravity kicks in. Exactly. But the promise of Write once run everywhere had always been if you stayed within the confines of Java/JVM. There was never a promise, or implication, that it would cross-platform once you started mixing in with foreign code. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: assume, assert, enforce, @safe
On 01/08/2014 05:12, Walter Bright wrote: On 7/31/2014 2:21 PM, Sean Kelly wrote: Thoughts? If a process detects a logic error, then that process is in an invalid state that is unanticipated and unknown to the developer. The only correct solution is to halt that process, and all processes that share memory with it. Anything less is based on faith and hope. If it is medical, flight control, or banking software, I submit that operating on faith and hope is not acceptable. If it's a dvr or game, who cares :-) My dvr crashes regularly needing a power off reboot. If it's a game, who cares - Oh let's see... let's say I'm playing a game, and then there's a bug (which happens often). What would I prefer to happen: * a small (or big) visual glitch, like pixels out of place, corrupted textures, or 3D model of an object becoming deformed, or the physics of some object behaving erratically, or some broken animation. * the whole game crashes, and I lose all my progress? So Walter, which one do you think I prefer? Me, and the rest of the million gamers out there? So yeah, we care, and we are the consumers of an industry worth more than the movie industry. As a software developer, to dismiss these concerns is silly and unprofessional. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: assume, assert, enforce, @safe
On Thu, 18 Sep 2014 17:05:31 +0100 Bruno Medeiros via Digitalmars-d digitalmars-d@puremagic.com wrote: * a small (or big) visual glitch, like pixels out of place, corrupted textures, or 3D model of an object becoming deformed, or the physics of some object behaving erratically, or some broken animation. or the whole game renders itself unbeatable due to some correpted data, but you have no way to know it until you made it to the Final Boss and can never win that fight. ah, so charming! signature.asc Description: PGP signature
Re: code cleanup in druntime and phobos
On 03/09/2014 15:17, Bruno Medeiros wrote: On 02/09/2014 08:20, Dicebot wrote: While you may still clone the repository there is no way to use any of advanced / social features without creating GitHub account and those features are exactly why it gets used. With no support for anonymous / openID input it creates situation where you have to chose - go with competitors and lose notable amount of community attention or stay with GitHub even if actual technological features provided are sub-par. In the end it encourages harmful attitude there is nothing outside the GitHub which of course benefits its owners much more than any actual technological advantage GitHub features are sub-par?... To what, Bugzilla?? You must be kidding me, Github is way better... I have to partially retract this statement. There is some advanced functionality that Bugzilla has, that Github-Issues doesn't have (nor does it have a decent alternative). But the core functionality of the Github issue tracking system is still way better than the core functionality of Bugzilla, I find. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: code cleanup in druntime and phobos
On 05/09/2014 20:42, Dicebot wrote: On Friday, 5 September 2014 at 14:34:49 UTC, Bruno Medeiros wrote: On 04/09/2014 20:21, Kagamin wrote: It comprises a social network in a sense that every user has his own diary - a place to store and share his work, and users can follow and watch diaries they're interested in, and when they get notified on updates in the followed diaries, they instantly go there to like, discuss and comment. And - in case of github - contribute. I know that, but in Github its not common for people to follow other people. Rather, they follow repositories, or at most, organizations... That takes away a lot of the social aspect of it, since it's not people you are focused on. There is also little element of discovering new people through the people you already know (although that is technically possible), it's not a core competency of Github. At most you discover new repositories through the people you follow, but I would reckon even that is not a common workflow. Fundamentally the central unit of the network in Github is a repository (and perhaps organizations). The people unit is very secondary. Like I said, you can still consider Github to be a social network with a very loose definition of what a social network is, but nonetheless, I consider it significantly different than Facebook/Google+/MySpace/LinkedIn/Twitter/Instagram/tumblr/etc.. It is a social network because it relies on people interaction as its most important feature. Without PR discussions / reviews, without being able to subscribe to users / repositories and without big user base it would not have been that tempting to use. You don't go GitHub for its features, you do it for potential contributors that can be attracted that way (and won't come otherwise). This is a definitive trait of social network. You seem to interpret social aspect very literally here - it is not really important if people casually chat and friend each other. Important thing is that same social processes fuel it as ones that were studied in traditional social network - large user base that generates content for each other and naturally encourages each other to stay. I went to the great oracle (Wikipedia) to clarify what is the more formal and proper term for this. Fair enough, indeed the likes of Facebook/Google+/MySpace/LinkedIn/Twitter/Instagram/tumblr/etc. are more precisely called online social networking services. So ok, I concede that Github can be called a social network. Although under that interpretation so is any web forum or bulletin board that has more than a handful of people communicating. (Personally I would still prefer avoiding that term.) I change my point to say that Github is not a social networking service then. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Dependency management in D
Im running some tests with D. Was wondering whats the dependency story. Cant find any info online, searched for dlang dependency management and dlang dependency. Found bunch o dub stuff but not the nitty gritty. Unit of compilation is one D file but I saw if I pass several D files to the compiler only one .o file is generated. Whats the story there. Plus if I change a non template function in one module then theres no way to tell make no rebuild of modules importing it. The dmd -deps call seems to generate all recursively. In gcc/makedepend if one function changes only relinking is needed or nothing if dynamic loading. Overall as far as I understand compiler is fast but dependency mgmt is coarse. Also whats the deal with cyclic dependencies. I saw discussion that its not possible but wrote a few test modules and it works fine. Am I grokking this and how can I help it thanx.
Re: assume, assert, enforce, @safe
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d wrote: On 01/08/2014 05:12, Walter Bright wrote: On 7/31/2014 2:21 PM, Sean Kelly wrote: Thoughts? If a process detects a logic error, then that process is in an invalid state that is unanticipated and unknown to the developer. The only correct solution is to halt that process, and all processes that share memory with it. Anything less is based on faith and hope. If it is medical, flight control, or banking software, I submit that operating on faith and hope is not acceptable. If it's a dvr or game, who cares :-) My dvr crashes regularly needing a power off reboot. If it's a game, who cares - Oh let's see... let's say I'm playing a game, and then there's a bug (which happens often). What would I prefer to happen: * a small (or big) visual glitch, like pixels out of place, corrupted textures, or 3D model of an object becoming deformed, or the physics of some object behaving erratically, or some broken animation. * the whole game crashes, and I lose all my progress? [...] What if the program has a bug that corrupts your save game file, but because the program ignores these logic errors, it just bumbles onward and destroys all your progress *without* you even knowing about it until much later? (I have actually experienced this firsthand, btw. I found it *far* more frustrating than losing all my progress -- at least I can restore the game to the last savepoint, and have confidence that it isn't irreparably corrupted! I almost threw the computer out the window once when after a game crash I restored the savefile, only to discover a few hours later that due to a corruption in the savefile, it was impossible to win the game after all. Logic errors should *never* have made it past the point of detection.) T -- People tell me I'm stubborn, but I refuse to accept it!
Re: assume, assert, enforce, @safe
On Thu, Sep 18, 2014 at 07:13:48PM +0300, ketmar via Digitalmars-d wrote: On Thu, 18 Sep 2014 17:05:31 +0100 Bruno Medeiros via Digitalmars-d digitalmars-d@puremagic.com wrote: * a small (or big) visual glitch, like pixels out of place, corrupted textures, or 3D model of an object becoming deformed, or the physics of some object behaving erratically, or some broken animation. or the whole game renders itself unbeatable due to some correpted data, but you have no way to know it until you made it to the Final Boss and can never win that fight. ah, so charming! Exactly Seriously, this philosophy of ignoring supposedly minor bugs in software is what led to the sad state of software today, where nothing is reliable and people have come to expect that software will inevitably crash, and that needing to reboot an OS every now and then just to keep things working is acceptable. Yet, strangely enough, people will scream bloody murder if a car behaved like that. T -- Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. -- Tom Stoppard
Re: Dependency management in D
On Thursday, 18 September 2014 at 16:48:22 UTC, Scott Wilson wrote: Unit of compilation is one D file but I saw if I pass several D files to the compiler only one .o file is generated. Whats the story there. DMD will generate one object file per module file, unless you use the -of option. With -of, the compiler will compile all module files to a single object file. Plus if I change a non template function in one module then theres no way to tell make no rebuild of modules importing it. The dmd -deps call seems to generate all recursively. In gcc/makedepend if one function changes only relinking is needed or nothing if dynamic loading. Yes, currently any changes, including function bodies, cause a rebuild of importing modules. One reason for this is CTFE - changing a function body can affect the code in importing modules if they invoke the function during compilation. You could use .di files to separate declarations from implementations. Overall as far as I understand compiler is fast but dependency mgmt is coarse. Also whats the deal with cyclic dependencies. I saw discussion that its not possible but wrote a few test modules and it works fine. Cyclic dependencies between modules which all have module or static constructors are forbidden, because it is unknown in which order the constructors are expected to run.
Re: Dependency management in D
On Thu, 18 Sep 2014 16:48:21 + Scott Wilson via Digitalmars-d digitalmars-d@puremagic.com wrote: Plus if I change a non template function in one module then theres no way to tell make no rebuild of modules importing it. The dmd -deps call seems to generate all recursively. In gcc/makedepend if one function changes only relinking is needed or nothing if dynamic loading. there is no way to tell what exactly was changed. this can be some template, for example, and with changed template all modules that import that one with template must be recompiled to accomodate new version. or think about CTFE. signature.asc Description: PGP signature
Defaulting delegate member variables to do-nothing stubs
I'm trying to write a struct with delegate member variables that I want
to default to do-nothing stubs (rather than null function pointers that
will crash when called), but it appears that such a thing is not
supported. I've tried all sorts of things, but none of them worked:
struct S {
void delegate(dchar) dg = (dchar) {};
// test.d(2): Error: delegate test.S.__lambda2 cannot be class
members
}
struct S {
void delegate(dchar) dg = {};
// test.d(2): Error: delegate test.S.__dgliteral2 cannot be
class members
}
void delegate(dchar) stub = (dchar) {};
struct S {
void delegate(dchar) dg = stub;
// test.d(3): Error: static variable stub cannot be read at
compile time
}
immutable(void delegate(dchar)) stub = (dchar) {};
// test.d(1): Error: non-constant nested delegate literal expression
__lambda4
// test.d(1): Error: non-constant nested delegate literal expression
__lambda4
// [Why the repeated message, and what on earth does this mean
// anyway?!]
struct S {
void delegate(dchar) dg = stub;
}
Is there a way to achieve this? If not, why not? Would it be worth
filing an enhancement request for this?
Note that the lack of argumentless struct ctors exacerbates this
problem, since there is no way to work around the lack of language
support here.
T
--
Береги платье снову, а здоровье смолоду.
Re: Library Typedefs are fundamentally broken
On Wednesday, 17 September 2014 at 02:57:03 UTC, Freddy wrote: When you have separate 2 typedefs of the exact same type, they are equal.While this maybe able to be solved with Typedef!(Typedef!(...)) different modules typedef ing the same type (most likely build-in types) would have their typedef be equivalent thereby degrading the purpose of typedef. --- import std.typecons; alias meter = Typedef!float; alias feet = Typedef!float; static assert(!is(meter==feet)); --- Your thoughts? Reading this thread and thinking on it more... I acknowledge this is probably kind of naive, but it makes aliases feel not-very-useful to me. It doesn't give you type checking or function overloading because as far as the semantic pass is concerned, they're identical. And that's fine. The documentation on AliasDeclaration is kind of verbose, but it does clarify that at some point (had to reread it a couple times to notice, though...). So I get that aliasing is at least situationally useful (e.g. utility shortening), and I think it's been stated repeatedly that it's great for metaprogramming things, but the aggregate makes this situation suck. If you want those things to work, you have to wrap it in a struct and use alias this (which IS a legitimately cool application of the aliasing semantics, I'll grant). This can be mitigated somewhat, but it still feels inelegant and not-D-like for something I'd really like to use easily and often. Also, for the hardcore among you, I think your cache may hate you for this (I don't recall if that overhead gets optimised away). I think you could be forgiven for expecting std.typecons.Typedef to provide the alternative we need, but it ends up being only about as useful as typedef in C (or maybe a bit less?). Is there some better solution I've missed? (I wouldn't consider the cookie parameter a better solution; I would consider it a wart.) -Wyatt
Re: code cleanup in druntime and phobos
I feel like this whole thread's diversion onto the relative merits of GitHub is pretty pointless. Would it be difficult to write a small automation tool that users could run (maybe distributed as part of the DMD package or something) that lets them submit patches/PRs mostly automatically? Or have a process which scans Bugzilla and produces such things automatically? I know I am not totally up on the infrastructure capabilities, but lowering the barrier to entry is almost always a good thing, and the religious arguments can be saved for alt.github.die.die.die or something.
Re: Library Typedefs are fundamentally broken
On Thu, Sep 18, 2014 at 05:48:30PM +, Wyatt via Digitalmars-d wrote:
[...]
If you want those things to work, you have to wrap it in a struct and
use alias this (which IS a legitimately cool application of the
aliasing semantics, I'll grant). This can be mitigated somewhat, but
it still feels inelegant and not-D-like for something I'd really like
to use easily and often. Also, for the hardcore among you, I think
your cache may hate you for this (I don't recall if that overhead gets
optimised away).
[...]
Why would your cache hate you for it? A struct that contains, say, a
single int, is at the assembly level identical to the int itself,
because structs are value types and they were basically designed to be
glorified ints, as Andrei puts it in TDPL. When you write something
like:
struct S {
int x;
alias x this;
// ...
}
S s;
s++;
basically s++ gets translated to s.x++, and since S behaves
basically identically to an int, which means it should get enregistered
under the same circumstances, the generated machine code should be
identical to when you wrote int instead of S.
I don't see why this should have any effect on the cache. Unless you
added extra fields to your struct where you shouldn't, and it becomes
too big to fit in registers, then it's not really the compiler's fault.
:-P
The neatest thing about this, is that any operator overloading you
implement for S will, in effect, behave like overloading the built-in
int operators; and if your operator overloads have simple
implementations, they will be inlined and you get basically a native
int but with overloaded operators. (This, of course, is the whole point
behind the 'checkedint' type currently used by some internal Phobos /
dmd functions. You basically have a type that's identical to int in
every way, except that some operations will have overflow checks
inserted in front in the machine code.)
This is why 'alias this' is such a total stroke of genius. It brings the
parity between user and built-in types to a whole new level of cool.
T
--
Curiosity kills the cat. Moral: don't be the cat.
Re: Defaulting delegate member variables to do-nothing stubs
On Thu, 18 Sep 2014 10:47:39 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
Is there a way to achieve this? If not, why not?
i believe that you can't put such delegate to .init due to
required context pointer. yet compiler must be able to detect that this
delegate is not using any context info and context pointer can be null
here.
Would it be worth filing an enhancement request for this?
yes, i think that ER will be fine.
Note that the lack of argumentless struct ctors exacerbates this
problem, since there is no way to work around the lack of language
support here.
the only way is to @disable this(), so nobody will create unitialized
struct. yet this reveals another bug(?):
struct S {
int v;
@disable this ();
this (int n=42) { v = n; }
}
void main () {
auto s = S();
}
z03.d(8): Error: constructor z03.S.this is not callable because it is
annotated with @disable
WHAT? we have a perfectly valid struct constructor with default arg
which can be called when S() constructed, yet compiler tells me that it
can't do that, 'cause i disabled completely different constructor?
this thing annoys me alot, and i believe that i will eventually fix it
regardless of it's status (bug/feature).
signature.asc
Description: PGP signature
Re: Now, a critic of Stroustrup's choices
On Thursday, 18 September 2014 at 09:16:39 UTC, Paulo Pinto wrote: These issues are touched in the book if I remember correctly. Yeah, but I don't have it and hoped you would give me some juicy quotes :). Quite a few C++ design decisions came from the requirement to fit 1:1 with C toolchains. Isn't it funny (or sad) though how the IT sector keeps being bogged down by clogged backwards compatibility issues going all the way back to the 60s and 70s? Now we need to wait for C++17, or do some marketing that D has them today. :) Hm, yes.
Re: Using D
Am 18.09.2014 17:44, schrieb Bruno Medeiros: On 06/09/2014 01:50, Paulo Pinto wrote: Am 05.09.2014 23:56, schrieb Dicebot: On Friday, 5 September 2014 at 14:18:46 UTC, Paulo Pinto wrote: You can write DLLs in Java, for example with http://www.excelsiorjet.com/. The fact that the Java reference implementation is a VM, doesn't tie the language to a VM. Why pick Java if not for JVM? It is mediocre language at most, very limited and poor feature-wise, lacking expressive power even compared to C++ (you can at least abuse templates in the latter). JVM, however, may be the best VM environment implementation out there and that can be useful. Enterprise answer: - lots of libraries to chose from; - lots of easy to find (replacable) programmers; -- Paulo Also, superior development-time tools: IDEs, debuggers. (the debugging support could be considered part of the JVM though, depending on how you look at it.) Also, me and a lot others don't agree Java is a mediocre language. It is basic language, yes. But a lot of good software can be written comfortably with just a basic language. C++ is more *powerful* than Java, but it doesn't mean its better. I would rather be programming in Java over C++, any time. I do like it, started playing with it around 1996 while at the university and our teachers made it right away the language for distributed systems (remember Jini?), software architecture and compiler design lectures (JavaCC ruled any day over yacc). My employer very seldom does C++, mainly JVM and .NET since that is what our enterprise customers ask us to do. However, thanks to Oracle disregard for the mobile space and the way Google tried to avoid paying for licenses, I am now forced to use C++ for portable native code across devices for hobby coding. Looking to see if Java One will bring any update on this regard as Oracle's current proposal of JSF on the server side for mobile development is a joke for any native developer. -- Paulo
Re: Defaulting delegate member variables to do-nothing stubs
On Thu, Sep 18, 2014 at 09:08:03PM +0300, ketmar via Digitalmars-d wrote:
On Thu, 18 Sep 2014 10:47:39 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
Is there a way to achieve this? If not, why not?
i believe that you can't put such delegate to .init due to
required context pointer. yet compiler must be able to detect that this
delegate is not using any context info and context pointer can be null
here.
Would it be worth filing an enhancement request for this?
yes, i think that ER will be fine.
Right, that's the underlying problem. The compiler doesn't know that the
context pointer is not being used, so it bails out when not given a
context to point the pointer at.
https://issues.dlang.org/show_bug.cgi?id=13494
Note that the lack of argumentless struct ctors exacerbates this
problem, since there is no way to work around the lack of language
support here.
the only way is to @disable this(), so nobody will create unitialized
struct. yet this reveals another bug(?):
struct S {
int v;
@disable this ();
this (int n=42) { v = n; }
}
void main () {
auto s = S();
}
z03.d(8): Error: constructor z03.S.this is not callable because it is
annotated with @disable
WHAT? we have a perfectly valid struct constructor with default arg
which can be called when S() constructed, yet compiler tells me that it
can't do that, 'cause i disabled completely different constructor?
this thing annoys me alot, and i believe that i will eventually fix it
regardless of it's status (bug/feature).
I think that should be filed as a bug. If the default ctor can't be
called (due to @disable), but there's another ctor with default
parameters, then the latter should be called instead.
T
--
The trouble with TCP jokes is that it's like hearing the same joke over and
over.
Re: Now, a critic of Stroustrup's choices
Am 18.09.2014 20:10, schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com: On Thursday, 18 September 2014 at 09:16:39 UTC, Paulo Pinto wrote: These issues are touched in the book if I remember correctly. Yeah, but I don't have it and hoped you would give me some juicy quotes :). The book is a few thousand kilometres from my current location. So no chance. Quite a few C++ design decisions came from the requirement to fit 1:1 with C toolchains. Isn't it funny (or sad) though how the IT sector keeps being bogged down by clogged backwards compatibility issues going all the way back to the 60s and 70s? Yes, which is why incremental changes tend to win over disruptive ones. Then we also have certain technologies that become mainstream and destroy better ones (e.g. C). All the efforts the programming communities that care about safety now have to spend promoting languages like D to fix the security issues created by it. When more safer languages were already available at the time UNIX spread out of university labs. -- Paulo
Re: Defaulting delegate member variables to do-nothing stubs
On Thursday, 18 September 2014 at 17:49:34 UTC, H. S. Teoh via
Digitalmars-d wrote:
I'm trying to write a struct with delegate member variables
that I want
to default to do-nothing stubs (rather than null function
pointers that
will crash when called), but it appears that such a thing is not
supported.
[...]
Is there a way to achieve this?
Here's a hack:
struct S
{
union
{
struct
{
void* contextPtr;
void function(dchar, void* contextPtr) funcPtr = (a,
ignored) {writeln(a);};
}
void delegate(dchar) dg;
}
}
Re: Defaulting delegate member variables to do-nothing stubs
On Thu, 18 Sep 2014 11:44:59 -0700 H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: I think that should be filed as a bug. If the default ctor can't be called (due to @disable), but there's another ctor with default parameters, then the latter should be called instead. i added bugzilla entry: https://issues.dlang.org/show_bug.cgi?id=13495 not sure if this is a bug or ER, though. signature.asc Description: PGP signature
Re: Library Typedefs are fundamentally broken
On Thursday, 18 September 2014 at 18:02:08 UTC, H. S. Teoh via Digitalmars-d wrote: basically s++ gets translated to s.x++, and since S behaves basically identically to an int, which means it should get enregistered under the same circumstances, the generated machine code should be identical to when you wrote int instead of S. Oh, neat. I stand corrected on that point. Thanks. I don't see why this should have any effect on the cache. That's my mistake; I thought there was overhead for structs in D. Should have done my homework! It's too bad this does nothing for the usability issues. :/ -Wyatt
Re: Library Typedefs are fundamentally broken
On 9/17/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: It is pretty much default technique used any time new template instance needs to be forced. Sound or not, I am not aware of any other even remotely reliable library approaches (it works pretty good for me actually). Actually, there is just one small issue with it (rare enough to almost never occur). Two instances on the same line will use the same line, e.g.: Foo!() x; Foo!() y; But there would be a simple way to fix this, by introducing __COLUMN__. But I don't know, it's using an AK47 to shoot a fly. There are more important enhancements I guess. :p
Re: Identifier resolution, the great implementation defined mess.
On Wednesday, 17 September 2014 at 22:42:27 UTC, deadalnix wrote: On Wednesday, 17 September 2014 at 16:25:57 UTC, Dicebot wrote: I had impression that general rule is most inner scope takes priority (with base classes being one imaginary scope above the current one). Are there any actual inconsistencies you have noticed or it just a matter of lacking matching spec entry? There is no inconsistencies because there is no spec. Maybe in this case it is best to just look at what dmd does and add that to the spec (assuming what dmd does is sound, and makes sense).
Re: assume, assert, enforce, @safe
The point is that using these enforce() statements means that
these methods cannot be nothrow, which doesn't seem
particularly nice if it can be avoided. Now, on the one hand,
one could say that, quite obviously, these methods cannot
control their input. But on the other hand, it's reasonable to
say that these methods' input can and should never be anything
other than 100% controlled by the programmer.
My take is that, for this reason, these should be asserts and
not enforce() statements. What are your thoughts on the matter?
Assert's are disable by -release option. If you want to do check,
and don't want to raise exception you can define special function
like this:
import std.stdio;
void enforceNoThrow(bool pred, string msg, string file =
__FILE__, uint line = __LINE__)
{
if (!pred)
{
stderr.writefln(Fatal error: %s at %s:%s, msg, file,
line);
assert(0);
}
}
void doSomething(int min, int middle, int max)
{
enforceNoThrow(middle = min middle = max, middle out of
bounds);
}
doSomething(1, 5, 3); //prints error message into stderr and
terminate programm execution
This way is better for library code then asserts. Asserts should
be used for catching internal bugs, but incorrect code is
external bug (for extern library)
Re: Identifier resolution, the great implementation defined mess.
On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote: Maybe in this case And in every case. DMD's behavior is correct because it consistent with DMD.
Re: Using D
On Thursday, 18 September 2014 at 15:48:46 UTC, Bruno Medeiros wrote: On 05/09/2014 14:42, Chris wrote: A jar can only be used by another Java program. Making a Java program accessible to 3rd party software via a DLL is not so simple, and the JVM has to be up and running all the time. Java is cross-platform as long as you stay within the safe and cosy Java bubble that floats on top of the JVM. But once you step outside of the JVM, gravity kicks in. Exactly. But the promise of Write once run everywhere had always been if you stayed within the confines of Java/JVM. There was never a promise, or implication, that it would cross-platform once you started mixing in with foreign code. Write once, debug everywhere is more accurate. Still prefers coding in java rather than C++ .
Remove dlang.org/library/ from search results?
The DDox documentation generator (and DMD's JSON output, which it heavily relies on) still seems to have a far way to go, as can be seen from the project's numerous open reported issues[1] and multiple problems with pages such as [2]. I've been getting the DDox versions of Phobos documentation at the top of my Google search results, which is a little annoying. We could remove the pages from search engines via robots.txt until DDox is ready. Should they be removed from Google for now? Or does anyone find them useful? [1]: https://github.com/rejectedsoftware/ddox/issues [2]: http://dlang.org/library/std/process/execute.html
Re: Identifier resolution, the great implementation defined mess.
On 09/19/2014 12:06 AM, Brian Schott wrote: On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote: Maybe in this case And in every case. DMD's behavior is correct because it consistent with DMD. ???
Re: Identifier resolution, the great implementation defined mess.
On Thursday, 18 September 2014 at 23:14:41 UTC, Timon Gehr wrote: On 09/19/2014 12:06 AM, Brian Schott wrote: On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote: Maybe in this case And in every case. DMD's behavior is correct because it consistent with DMD. ??? http://en.wikipedia.org/wiki/Gallows_humor
Re: Dependency management in D
On Thursday, 18 September 2014 at 17:04:43 UTC, ketmar via Digitalmars-d wrote: On Thu, 18 Sep 2014 16:48:21 + Scott Wilson via Digitalmars-d digitalmars-d@puremagic.com wrote: Plus if I change a non template function in one module then theres no way to tell make no rebuild of modules importing it. The dmd -deps call seems to generate all recursively. In gcc/makedepend if one function changes only relinking is needed or nothing if dynamic loading. there is no way to tell what exactly was changed. this can be some template, for example, and with changed template all modules that import that one with template must be recompiled to accomodate new version. or think about CTFE. Thanks fellas. But whats the thing with .di files? AFAIU the compiler generates them and dependent modules can depend on them instead of .d files directly. Do .di files contain only templates (no comments and plain functions? How well do they work? thanx
Re: Dependency management in D
On Fri, 19 Sep 2014 01:42:58 +
Scott Wilson via Digitalmars-d digitalmars-d@puremagic.com wrote:
Do .di files contain only templates (no comments and plain
functions? How well do they work? thanx
as for 'how .di files work' question: '.di' is just a plain D source,
just with stripped function bodies. nothing very special about that.
so yes, .di files contains only templates and function declarations
(without function bodies). this *can* work, but when it comes to CTFE...
look at the following:
=== z00.d ===
module z00;
string foo(string name) { return `int `~name~`() {return 42;}`; }
=== z01.d ===
import z00;
mixin(foo(`bar`));
void main () {
import std.stdio;
writeln(bar());
}
and .di file generated with `dmd -H -c -o- z00.d`:
=== z00.di ===
// D import file generated from 'z00.d'
module z00;
string foo(string name);
do you see any gotchas? heh:
# dmd z01.d
z01.d(2): Error: foo cannot be interpreted at compile time, because it
has no available source code
z01.d(2): Error: argument to mixin must be a string, not (foo(bar))
of type string
the compiler has no source for foo() anymore, so it can't do CTFE.
you can avoid this by turning foo() into template:
string foo()(string name) { return `int `~name~`() {return 42;}`; }
but then you should turn all your functions that can be used in CTFE
into templates, and there will be no much sense in .di file anyway.
to make a long story short: don't use .di files unless you *REALLY*
*KNOW* what you're doing. and even then think twice.
signature.asc
Description: PGP signature
Re: Library Typedefs are fundamentally broken
On 9/18/14, 10:48 AM, Wyatt wrote: (I wouldn't consider the cookie parameter a better solution; I would consider it a wart.) That's the right solution. Andrei
Re: Remove dlang.org/library/ from search results?
On Friday, 19 September 2014 at 04:35:04 UTC, Andrei Alexandrescu wrote: On 9/18/14, 4:10 PM, Vladimir Panteleev wrote: The DDox documentation generator (and DMD's JSON output, which it heavily relies on) still seems to have a far way to go, as can be seen from the project's numerous open reported issues[1] and multiple problems with pages such as [2]. I've been getting the DDox versions of Phobos documentation at the top of my Google search results, which is a little annoying. We could remove the pages from search engines via robots.txt until DDox is ready. Should they be removed from Google for now? Or does anyone find them useful? [1]: https://github.com/rejectedsoftware/ddox/issues [2]: http://dlang.org/library/std/process/execute.html Is there a way to disable indexing by google yet keep them? -- Andrei Yes, listing them in robots.txt, which was what I suggested. I'm not saying we should actually remove them from the website :) We already have /phobos-prerelease/ and /library-prerelease/ in robots.txt: http://dlang.org/robots.txt
Re: Remove dlang.org/library/ from search results?
On 9/18/14, 4:10 PM, Vladimir Panteleev wrote: The DDox documentation generator (and DMD's JSON output, which it heavily relies on) still seems to have a far way to go, as can be seen from the project's numerous open reported issues[1] and multiple problems with pages such as [2]. I've been getting the DDox versions of Phobos documentation at the top of my Google search results, which is a little annoying. We could remove the pages from search engines via robots.txt until DDox is ready. Should they be removed from Google for now? Or does anyone find them useful? [1]: https://github.com/rejectedsoftware/ddox/issues [2]: http://dlang.org/library/std/process/execute.html Is there a way to disable indexing by google yet keep them? -- Andrei
Once in a while, you got to stop complaining and say thank you.
Not so long ago, SDC used to require more than 2.5Gb of RAM and minutes to compile, and it wasn't possible to compile it as separate modules due to various bugs in the frontend. Now it is not only possible to compile it as separates modules, but I was able recently to reenable the compilation of all libd at once, as it is no much faster. I can now compile SDC on my machine in 10s to 11s, linking included, and less than 500Mb of RAM. That is a huge step forward to me, and probably to some other D users. SO, once in a while, you got to stop complaining, and say a big thank you to all of you here that contribute to DMD.
Re: Library Typedefs are fundamentally broken
On Wednesday, 17 September 2014 at 16:32:04 UTC, Dicebot wrote: On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack Applegame wrote: You can use module name and line number as unique tag. This is exactly what I would have expected as default behaviour. Is anyone aware why this counter appoach was used instead? It's a deceivingly bad default. See the comments in the PR that introduced Typedef[1]. [1] https://github.com/D-Programming-Language/phobos/pull/300
Totally bizarre error, requesting assistance
I don't know if this is the right place to ask, but I figured it was worth a try. Basically, I'm getting totally bizarre behaviour from my code, which I have put in a repo at https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541: To replicate the error, simply run 'make profile' from the project directory. It should fail (claiming an enforcement error on node.d, line 50). Then, go to tournament.d, and uncomment line 33. Then, try 'make profile' again, and it won't have the same issue. I've been working all day to try and isolate the source of the problem, across multiple machines, and I've had no luck. This is the most isolation I've managed. I would really appreciate any and all help, as this is something that totally baffles me. I know this is a lot of code, and it's probably quite hideous, but it would help me a lot if someone could at least suggest as to where the source of the problem lies. I already am aware that the failure is caused by an overflow, but its source is completely unclear, and I never get overflows when that one writeln statement in tournament.d is executed (hence my confusion). I'm running Manjaro GNU/Linux, and my gdc version is 4.9.1. I have a 64-bit OS.
Re: Remove dlang.org/library/ from search results?
On Friday, 19 September 2014 at 04:37:22 UTC, Vladimir Panteleev wrote: Yes, listing them in robots.txt, which was what I suggested. I'm not saying we should actually remove them from the website :) We already have /phobos-prerelease/ and /library-prerelease/ in robots.txt: http://dlang.org/robots.txt I think we should do it, but robots.txt is tracked by the git repository, so might as well continue this in a PR?
Re: Totally bizarre error, requesting assistance
You should try dustmite to reduce the problem further: https://github.com/CyberShadow/DustMite
Re: Totally bizarre error, requesting assistance
On Friday, 19 September 2014 at 04:46:56 UTC, Koz Ross wrote: I don't know if this is the right place to ask, but I figured it was worth a try. Basically, I'm getting totally bizarre behaviour from my code, which I have put in a repo at https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541: I can't reproduce this. It's probably related to GDC. Can you try a different D compiler? If you can't reproduce the problem with DMD, you should post in the GDC group: http://forum.dlang.org/group/D.gnu Have you heard of DustMite? It can automate the process of reducing your code to a minimal test case: https://github.com/CyberShadow/DustMite/ To replicate the error, simply run 'make profile' from the project directory. It should fail (claiming an enforcement error on node.d, line 50). There is no enforce call on node.d line 50. Is the uploaded source code correct, or is this part of the problem?
Re: Totally bizarre error, requesting assistance
On Friday, 19 September 2014 at 04:55:34 UTC, Vladimir Panteleev wrote: On Friday, 19 September 2014 at 04:46:56 UTC, Koz Ross wrote: I don't know if this is the right place to ask, but I figured it was worth a try. Basically, I'm getting totally bizarre behaviour from my code, which I have put in a repo at https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541: I can't reproduce this. It's probably related to GDC. Can you try a different D compiler? If you can't reproduce the problem with DMD, you should post in the GDC group: http://forum.dlang.org/group/D.gnu Have you heard of DustMite? It can automate the process of reducing your code to a minimal test case: https://github.com/CyberShadow/DustMite/ To replicate the error, simply run 'make profile' from the project directory. It should fail (claiming an enforcement error on node.d, line 50). There is no enforce call on node.d line 50. Is the uploaded source code correct, or is this part of the problem? Hi Vladimir, First of all, thanks for the prompt response. The enforce call in question is actually on line 55, and looks like this: enforce(value 0) I added a few clarifying comments to the file, and I guess it changed the line number from what it was originally. I will try and compile this under dmd and see if I have the same problem. I haven't heard of DustMite, but I'll also look into that. Thanks!
Re: Totally bizarre error, requesting assistance
On Friday, 19 September 2014 at 04:55:34 UTC, Vladimir Panteleev wrote: On Friday, 19 September 2014 at 04:46:56 UTC, Koz Ross wrote: I don't know if this is the right place to ask, but I figured it was worth a try. Basically, I'm getting totally bizarre behaviour from my code, which I have put in a repo at https://gitorious.org/tournament-tree/tournament-tree/source/545460fb9d760b6bfa5bc74deb7b69d79ec70541: I can't reproduce this. It's probably related to GDC. Can you try a different D compiler? If you can't reproduce the problem with DMD, you should post in the GDC group: http://forum.dlang.org/group/D.gnu Have you heard of DustMite? It can automate the process of reducing your code to a minimal test case: https://github.com/CyberShadow/DustMite/ To replicate the error, simply run 'make profile' from the project directory. It should fail (claiming an enforcement error on node.d, line 50). There is no enforce call on node.d line 50. Is the uploaded source code correct, or is this part of the problem? Following up on this, under DMD, I get the enforcement failure on line 55 with and without the print statement. Now I'm even more confused.
Re: Once in a while, you got to stop complaining and say thank you.
On 9/18/2014 9:35 PM, deadalnix wrote: Not so long ago, SDC used to require more than 2.5Gb of RAM and minutes to compile, and it wasn't possible to compile it as separate modules due to various bugs in the frontend. Now it is not only possible to compile it as separates modules, but I was able recently to reenable the compilation of all libd at once, as it is no much faster. I can now compile SDC on my machine in 10s to 11s, linking included, and less than 500Mb of RAM. That is a huge step forward to me, and probably to some other D users. SO, once in a while, you got to stop complaining, and say a big thank you to all of you here that contribute to DMD. My pleasure!
Re: Once in a while, you got to stop complaining and say thank you.
On Fri, 19 Sep 2014 04:35:54 + deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: SO, once in a while, you got to stop complaining, and say a big thank you to all of you here that contribute to DMD. i may seem rude and may write and write alot of posts with BS!, WUT?!, this SUX, but i really appreciate all the efforts that people put into D. i can dislike some decisions, but i really love D, it's great! and what makes D great is people who using it, reporting bugs, writing ERs and writing the actual code which fuels the wrole thing. not only compiler, but tools, libraries, articles, books and so on. thank you, people! you are great, all of you. signature.asc Description: PGP signature
Re: Totally bizarre error, requesting assistance
On Fri, 19 Sep 2014 04:55:32 + Vladimir Panteleev via Digitalmars-d digitalmars-d@puremagic.com wrote: Have you heard of DustMite? It can automate the process of reducing your code to a minimal test case: https://github.com/CyberShadow/DustMite/ i think that we must have DustMite on the main D page. it's a great tool, yet most people can find it only by accident or by reading posts of other people who mention it. signature.asc Description: PGP signature
Re: Totally bizarre error, requesting assistance
On Fri, 19 Sep 2014 04:46:55 + Koz Ross via Digitalmars-d digitalmars-d@puremagic.com wrote: To replicate the error, simply run 'make profile' from the project directory. It should fail (claiming an enforcement error on node.d, line 50). no failuers for me. Slackware GNU/Linux, x86, gcc 4.9.1 and gdc-4.9-head (yet with some fixes backported from master, but they shouldn't make any difference). it also works perfectly with dmd-head. signature.asc Description: PGP signature
Re: Dependency management in D
On 9/18/2014 9:48 AM, Scott Wilson wrote: Im running some tests with D. Was wondering whats the dependency story. Cant find any info online, searched for dlang dependency management and dlang dependency. Found bunch o dub stuff but not the nitty gritty. Unit of compilation is one D file but I saw if I pass several D files to the compiler only one .o file is generated. Whats the story there. The idea is to essentially pre-link the object files that would have been generated if the files were compiled individually into one object file. This is faster and more convenient. It also means that semantic analysis is done only once for each file, and the imports, rather than doing it over and over as is done with separate compilation. Plus if I change a non template function in one module then theres no way to tell make no rebuild of modules importing it. The dmd -deps call seems to generate all recursively. In gcc/makedepend if one function changes only relinking is needed or nothing if dynamic loading. Dependency management is the same as in C++, if you are willing to use .di files to represent 'headers' of corresponding .d files. Overall as far as I understand compiler is fast but dependency mgmt is coarse. Also whats the deal with cyclic dependencies. I saw discussion that its not possible but wrote a few test modules and it works fine. If two modules import each other, then if one changes, both should get recompiled.
Re: Dependency management in D
On 9/18/2014 9:56 AM, Vladimir Panteleev wrote: On Thursday, 18 September 2014 at 16:48:22 UTC, Scott Wilson wrote: Unit of compilation is one D file but I saw if I pass several D files to the compiler only one .o file is generated. Whats the story there. DMD will generate one object file per module file, unless you use the -of option. This is incorrect. It'll generate one object file per invocation of dmd.
Re: Voting: std.logger
Am Tue, 16 Sep 2014 21:22:36 +
schrieb Robert burner Schadek rburn...@gmail.com:
On Wednesday, 10 September 2014 at 16:54:14 UTC, Dicebot wrote:
so the current version has one template args log functions that
take __LINE__ and friends as normal parameter.
I think that was the last complaint, please correct me if I'm
wrong.
WAT?
So next round?
Hell no!
Am Mon, 15 Sep 2014 22:33:45 +
schrieb Robert burner Schadek rburn...@gmail.com:
again, the idea of std.logger is not to give you everything,
because nobody knows what that even is, the idea is to make it
possible to do everything and have it understandable later and
use transparently
I understand that part Robert, and already made use of that
flexibility. But you use this to play down any concerns about
the thread safety of the infrastructure you wrote and finally
get std.logger accepted and merged.
the threading behavior has been clarified in the api docs.
You can't just clarify it in the docs.
It requires actual code to work both ways.
the (a)synchronicity guarantees is part of the concrete Logger
impl. the Logger api does not force synchronize or asynchronize
behavior, it allows both to be implemented by every subclass of
Logger.
All access to global state has to be synchronized before we
can safely do so, and std.logger doesn't even attempt to in its
current state! Some examples:
SITUATION:
isLoggingEnabled(LogLevel ll, LogLevel loggerLL, LogLevel
globalLL, lazy bool condition)
{
…
return ll = globalLL
ll = loggerLL
globalLL != LogLevel.off
loggerLL != LogLevel.off
condition
}
@property LogLevel globalLogLevel() @trusted @nogc
{
return globalLogLevelImpl();
}
private ref LogLevel globalLogLevelImpl() @trusted @nogc
{
static __gshared LogLevel ll = LogLevel.all;
return ll;
}
is called like this:
isLoggingEnabled(stdlog.logLevel, stdlog.logLevel,
globalLogLevel,
condition);
Inside `isLoggingEnabled`, we can expect condition to be
evaluated in the context of the calling thread, but the three
log level variables passed in create a race condition.
Imagine another thread sets `stdlog.logLevel` from warning to
error during a logging call. Inside `isLoggingEnabled` you'd
now get:
return LogLevel.warning = globalLL
LogLevel.warning = LogLevel.error
globalLL != LogLevel.off
loggerLL != LogLevel.off
condition
This will unconditionally return false of course. The `stdlog`
is now at log level warning AND error at the same time. WAT?
EFFECT:
Every blue moon a log message will be swallowed by std.logger.
SITUATION:
private Mutex __stdloggermutex;
static this() {
__stdloggermutex = new Mutex;
}
@property ref Logger stdlog() @trusted
{
static __gshared bool once;
static __gshared Logger logger;
static __gshared ubyte[__traits(classInstanceSize,
FileLogger)] buffer;
__stdloggermutex.lock();
scope(exit) __stdloggermutex.unlock();
if (!once)
{
once = true;
logger = emplace!FileLogger(buffer, stderr,
globalLogLevel()); }
return logger;
}
Every thread will now create its own thread local mutex to
protect access to global state.
EFFECT:
** This protects exactly nothing. **
Write instead:
__gshared private Mutex __stdloggermutex;
shared static this() {
__stdloggermutex = new Mutex;
}
If you need help with multi-threading please ask either here or
on IRC. I have found that we have some people in the community
that can explain even the fine details of atomic fences.
SITUATION:
We set the global log level through `globalLogLevel`:
@property void globalLogLevel(LogLevel ll) @trusted
{
if (stdlog !is null)
{
stdlog.logLevel = ll;
}
globalLogLevelImpl = ll;
}
What you tried here, was to set the global log level in case
we don't have `stdlog` initialized already, because during its
creation it will pick up the global log level.
Now `globalLogLevelImpl = ll;` will never be executed, because
inside the `stdlog` property function, it is initialized and
thus `stdlog !is null` will always be true.
Unless the user sets `stdlog` to null, which I assume is
invalid, since it creates fuzzy semantics: The first time
`stdlog` is encountered to be null it is set to a FileLogger,
any other time it stays null.
EFFECT:
There is no synchronization around the access to the stdlog.
D as far as I know doesn't require that machine word
reads/writes are atomic, so in theory you could get a
`stdlog` where one half is an old value and the other a new
one. That won't happen on ARM and x86, but I thought I'd
mention. Much more importantly though another thread could
change `stdlog` between `stdlog !is null` and
`stdlog.logLevel = ll;`. Assuming you want to protect all
of the global state with
Re: std.experimental.logger: practical observations
Please see the review thread for some long comment on multi-threading issues with this design. -- Marco
Re: Dependency management in D
On Friday, 19 September 2014 at 05:19:07 UTC, Walter Bright wrote: On 9/18/2014 9:56 AM, Vladimir Panteleev wrote: On Thursday, 18 September 2014 at 16:48:22 UTC, Scott Wilson wrote: Unit of compilation is one D file but I saw if I pass several D files to the compiler only one .o file is generated. Whats the story there. DMD will generate one object file per module file, unless you use the -of option. This is incorrect. It'll generate one object file per invocation of dmd. Erm, that's not quite correct either. I meant, one object file per module file passed on the command line.
Re: Library Typedefs are fundamentally broken
Andrei Alexandrescu: Wyatt: (I wouldn't consider the cookie parameter a better solution; I would consider it a wart.) That's the right solution. The cookie parameter is a ugly wart. Bye, bearophile
std.utf.decode(dlang, 1)
void main()
{
import std.utf;
decode(dlang, 1);
}
Error: template std.utf.decode cannot deduce function from
argument types !()(string, int), candidates are:
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(924):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(!isSomeString!S isRandomAccessRange!S hasSlicing!S
hasLength!S isSomeChar!(ElementType!S))
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(942):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S)
why doesn't decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S) correspond?
Re: std.utf.decode(dlang, 1)
On Thursday, 18 September 2014 at 06:09:54 UTC, Algo wrote:
void main()
{
import std.utf;
decode(dlang, 1);
}
Error: template std.utf.decode cannot deduce function from
argument types !()(string, int), candidates are:
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(924):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(!isSomeString!S isRandomAccessRange!S hasSlicing!S
hasLength!S isSomeChar!(ElementType!S))
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(942):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S)
why doesn't decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S) correspond?
rvalues cannot be ref it seems
Re: Interop with C++ library - what toolchain do you use?
On 18/09/14 00:28, Cliff wrote: So I am trying to use a C++ library with D. My toolchain is currently Visual Studio 2013 with Visual D, using the DMD compiler. When trying to link, I obviously ran into the OMF vs. COFF issue DMD has always produce COFF for Windows 64bit. Recently it also got support for COFF in 32bit. I don't think this has been released yet, but it's available in git master. -- /Jacob Carlborg
Re: std.utf.decode(dlang, 1)
On 09/17/2014 11:23 PM, Algo wrote:
On Thursday, 18 September 2014 at 06:09:54 UTC, Algo wrote:
void main()
{
import std.utf;
decode(dlang, 1);
}
Error: template std.utf.decode cannot deduce function from
argument types !()(string, int), candidates are:
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(924):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(!isSomeString!S isRandomAccessRange!S hasSlicing!S
hasLength!S isSomeChar!(ElementType!S))
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(942):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S)
why doesn't decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S) correspond?
rvalues cannot be ref it seems
Yes. Interestingly, in D rvalues cannot be bound even to const ref.
void main()
{
import std.stdio;
import std.utf;
size_t index = 1;
dchar decoded = decode(dlang, index);
writefln(decoded '%s', next character is at index %s.,
decoded, index);
}
The output:
decoded 'l', next character is at index 2.
Ali
Re: GC-less Hash-Tables (AA)
On Wednesday, 17 September 2014 at 23:57:03 UTC, H. S. Teoh via Digitalmars-d-learn wrote: compile-time type information via templates. Ideally it should be a fully-decoupled library implementation interfacing with the compiler via a set API, but we're still some ways off from that right now. If you'd like to help it reach that point, it would be most welcome, but be aware that right now, doing things like changing the allocation scheme is not going to be an easy change. Very interesting, indeed. Do you have an D issue (list) to begin with? Thanks for now.
Re: Interop with C++ library - what toolchain do you use?
On Wednesday, 17 September 2014 at 22:28:44 UTC, Cliff wrote: So I am trying to use a C++ library with D. My toolchain is currently Visual Studio 2013 with Visual D, using the DMD compiler. When trying to link, I obviously ran into the OMF vs. COFF issue, which makes using the C++ library a bit of a trial to say the least (I played around with some lib format converters but perhaps unsurprisingly this led to somewhat unpredictable behavior.) I'd like to fix up my toolchain to avoid having this issue. For those of you who are on Windows and who do D and C++ interop, what toolchain have you had success with? Additionally, I have heard tell that D now allows calling C++ non-virtual class methods but I have not found documentation on how to make this work (how do I define the C++ class layout in D - I know how to do it for vtable entries but not non-virtual methods.) Pointers to docs or samples would be much appreciated. Thanks! I am using Visual Studio 2012 (in x64 bit mode that is). Binary D distribution also comes with phobos64.lib that C++ executable has to link. With VisualD plugin you can just add D static library project to the solution and the link C++ exe to it. It is very easy to make back-and-forth function calls between C++/D. I recommend Adam Ruppe's excellent D Cookbook Integration chapter on the details on how to expose this for cross-lang usage. It does not all work correctly tho. I reported my issues on learn subforum but didn't get much help. In short: it seems not everything in D run-time (Phobos) gets properly initialized even after successful rt_init() call. In my case simple call to writeln() causes a crash because stdout is not properly initialized on D'd side. Happy hybridizing!
Re: input range from stdin
On Wednesday, 17 September 2014 at 18:05:36 UTC, Ali Çehreli
wrote:
On 09/17/2014 08:30 AM, krzaq wrote:
On Wednesday, 17 September 2014 at 14:37:21 UTC, Marc Schütz
wrote:
On Wednesday, 17 September 2014 at 12:44:00 UTC, krzaq wrote:
I'd like to have something similar to C++'s
std::istream_iteratorint(std::cin)
Is it possible? I'm relatively indifferent to efficiency of
the
solution.
import std.stdio;
import std.algorithm;
import std.conv;
writeln(stdin.byLine.map!(to!int));
What happens if I later have some strings that I want to read
from the
same line?
How can I use the resultant range with std.fill?
My idea doesn't seem to work:
http://dpaste.dzfl.pl/130e14c927f3
The following worked:
import std.stdio;
import std.format;
import std.exception;
import std.string;
import std.algorithm;
struct Data
{
int i;
string s;
}
Data toData(char[] line)
{
int i;
string s;
auto slice = line;
const items = formattedRead(line, %s %s, i, s);
enforce (items == 2, format(Incomplete line: %s, slice));
return Data(i, s);
}
void main()
{
auto data = stdin.byLine.map!toData;
writeln(data);
}
I could not get it work with fill because fill requires
specific types of ranges, which neither the destination nor the
source were. For example, I wanted to use std.array.Appender
but fill wants an InputRange. Also, the source is not a
ForwardRange because it is consuming from stdin.
However, it is easy to make an array with std.array.array:
import std.array;
writeln(data.array);
Ali
Thank you for your reply.
That's not what I wanted. Maybe I should explain instead of
expecting you to divine my intentions, though :) I am trying to
rewrite the following program in D--making it more elegant:
http://melpon.org/wandbox/permlink/ff42FoyKgqJK60sm
As you can see, I can have one input line consisting of n words
and then n integers and I can read from it easily. My question
whether stdin.byLine allows me to do this remains unanswered (or
I failed to understand the answer), although I am not hopeful.
As to std.fill: I find myself surprised. Any idea why the input
range is considered incorrect? In any case, should
integers[0..$].fill(...) not make it correct, at least in regards
to the first argument? Docs have an example with int[]
I expected my D code to look more or less like the following:
words.fill(stdin.by!string);
integers.fill(stdin.by!int);
zip(integers,words).map!(p = p[1][p[0]]).join.writeln;
Re: GC-less Hash-Tables (AA)
See our hashmap and hashset implementations here: https://github.com/economicmodeling/containers/tree/master/src/containers These containers are all certified GC-free. I get loads of erros on DMD 2.066: memory/allocators.d(81,4): Error: pure function 'memory.allocators.BlockAllocator!1024LU.BlockAllocator.~this' cannot access mutable static data 'it' memory/allocators.d(81,4): Error: pure function 'memory.allocators.BlockAllocator!1024LU.BlockAllocator.~this' cannot access mutable static data 'it' memory/allocators.d(81,28): Error: pure function 'memory.allocators.BlockAllocator!1024LU.BlockAllocator.~this' cannot call impure function 'std.allocator.Mallocator.deallocate' memory/allocators.d(81,28): Error: 'std.allocator.Mallocator.deallocate' is not nothrow memory/allocators.d(72,2): Error: destructor 'memory.allocators.BlockAllocator!1024LU.BlockAllocator.~this' is nothrow yet may throw memory/allocators.d(20,34): Error: template instance memory.allocators.BlockAllocator!1024LU error instantiating /home/per/Work/justd/containers/hashmap.d(339,29): instantiated from here: NodeAllocator!(32LU, 1024LU) /home/per/Work/justd/containers/hashmap.d(13,18): instantiated from here: HashMap!(string, int, hashString) /home/per/Work/justd/containers/hashmap.d(351,12): instantiated from here: HashMap!(string, int) /home/per/Work/justd/containers/hashmap.d(340,17): Error: template instance Freelist!(BlockAllocator!1024LU, 32LU, 32LU) is used as a type /home/per/Work/justd/containers/hashmap.d(341,22): Error: template instance Freelist!(BlockAllocator!1024LU, 32LU, 32LU) is used as a type /home/per/Work/justd/containers/hashmap.d(342,11): Error: template instance SList!(Node, SListNodeAllocator*) is used as a type /home/per/Work/justd/containers/hashmap.d(55,3): Error: undefined identifier deallocate, did you mean template reallocate(Allocator)(ref Allocator a, ref void[] b, size_t s)? /home/per/Work/justd/containers/hashmap.d(340,17): Error: template instance Freelist!(BlockAllocator!1024LU, 8LU, 8LU) is used as a type /home/per/Work/justd/containers/hashmap.d(341,22): Error: template instance Freelist!(BlockAllocator!1024LU, 8LU, 8LU) is used as a type /home/per/Work/justd/containers/hashmap.d(342,11): Error: template instance SList!(Node, SListNodeAllocator*) is used as a type /home/per/Work/justd/containers/hashmap.d(55,3): Error: undefined identifier deallocate, did you mean template reallocate(Allocator)(ref Allocator a, ref void[] b, size_t s)? /home/per/Work/justd/containers/hashmap.d(19,18): Error: template instance containers.hashmap.HashMap!(char, char, builtinHash) error instantiating /home/per/Work/justd/containers/hashmap.d(372,13): instantiated from here: HashMap!(char, char) memory/allocators.d(81,4): Error: pure function 'memory.allocators.BlockAllocator!512LU.BlockAllocator.~this' cannot access mutable static data 'it' memory/allocators.d(81,4): Error: pure function 'memory.allocators.BlockAllocator!512LU.BlockAllocator.~this' cannot access mutable static data 'it' memory/allocators.d(81,28): Error: pure function 'memory.allocators.BlockAllocator!512LU.BlockAllocator.~this' cannot call impure function 'std.allocator.Mallocator.deallocate' memory/allocators.d(81,28): Error: 'std.allocator.Mallocator.deallocate' is not nothrow memory/allocators.d(72,2): Error: destructor 'memory.allocators.BlockAllocator!512LU.BlockAllocator.~this' is nothrow yet may throw memory/allocators.d(20,34): Error: template instance memory.allocators.BlockAllocator!512LU error instantiating Compilation finished at Thu Sep 18 12:20:19
Re: GC-less Hash-Tables (AA)
On Thursday, 18 September 2014 at 10:21:29 UTC, Nordlöw wrote: These containers are all certified GC-free. I get loads of erros on DMD 2.066: My mistake. I hade accidentally used another version of std.allocator.
Re: dub can't read files from cache
Windows has full support for unicode, since it's an OS based on unicode. It's old C code, which is not unicode-ready, and it remains not unicode-ready without changing behavior. Modern code like phobos usually tries to be unicode-ready.
Re: input range from stdin
On Thursday, 18 September 2014 at 09:21:17 UTC, krzaq wrote: That's not what I wanted. Maybe I should explain instead of expecting you to divine my intentions, though :) I am trying to rewrite the following program in D--making it more elegant: http://melpon.org/wandbox/permlink/ff42FoyKgqJK60sm As you can see, I can have one input line consisting of n words and then n integers and I can read from it easily. My question whether stdin.byLine allows me to do this remains unanswered (or I failed to understand the answer), although I am not hopeful. You should be able to use `std.algorithm.take` to read exactly 5 integers. However, in order to read up to the first empty line, for example, the input would have to be a forward range (= rewindable), which stdin.byLine of course is not. Maybe you could constructor a wrapper range that caches input lines as necessary.
Re: input range from stdin
On Thursday, 18 September 2014 at 11:13:36 UTC, Marc Schütz wrote: On Thursday, 18 September 2014 at 09:21:17 UTC, krzaq wrote: That's not what I wanted. Maybe I should explain instead of expecting you to divine my intentions, though :) I am trying to rewrite the following program in D--making it more elegant: http://melpon.org/wandbox/permlink/ff42FoyKgqJK60sm As you can see, I can have one input line consisting of n words and then n integers and I can read from it easily. My question whether stdin.byLine allows me to do this remains unanswered (or I failed to understand the answer), although I am not hopeful. You should be able to use `std.algorithm.take` to read exactly 5 integers. However, in order to read up to the first empty line, for example, the input would have to be a forward range (= rewindable), which stdin.byLine of course is not. Maybe you could constructor a wrapper range that caches input lines as necessary. Okay, I think I'll simply skip this for now. I hoped that there would be a way of reading stdin composable with std.algorithms, as is the case in C++. I guess this works for now http://dpaste.dzfl.pl/6801615160e3 I have a follow-up question: why does zip not accept an array?
Re: std.utf.decode(dlang, 1)
On Thursday, 18 September 2014 at 06:09:54 UTC, Algo wrote:
void main()
{
import std.utf;
decode(dlang, 1);
}
Error: template std.utf.decode cannot deduce function from
argument types !()(string, int), candidates are:
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(924):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(!isSomeString!S isRandomAccessRange!S hasSlicing!S
hasLength!S isSomeChar!(ElementType!S))
D:\msc\D\dmd2\windows\bin\..\..\src\phobos\std\utf.d(942):
std.utf.decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S)
why doesn't decode(S)(auto ref S str, ref size_t index) if
(isSomeString!S) correspond?
I was having same issue a while ago. But I realized I was using
function in the wrong way with string type and passing a size_t
in the 2th argument. You can see use of decode(val, size) in the
standard library but call it in your code result in an error.
it worked:
string s = readText(file);
decode(cast(ubyte[]) s);
I'm not sure why you're trying to pass a string literal as
argument because it does need a memory location to change to new
memory location, where bytes skiped end. That's why it does use
ref.
Re: input range from stdin
On Thursday, 18 September 2014 at 13:10:06 UTC, krzaq wrote: I guess this works for now http://dpaste.dzfl.pl/6801615160e3 I have a follow-up question: why does zip not accept an array? Because (fixed-sized) arrays don't have a range interface (empty, front popFront()), in particular, popFront cannot be used on them. That's why a slice is needed. Btw, you can just write `array_name[]` without `0 .. $` to get a slice of the entire array.
Re: dub can't read files from cache
On Thursday, 18 September 2014 at 10:45:24 UTC, Kagamin wrote: Windows has full support for unicode, since it's an OS based on unicode. It's old C code, which is not unicode-ready, and it remains not unicode-ready without changing behavior. Modern code like phobos usually tries to be unicode-ready. Windows 9 will be based on Windows 98 =) Seriously, console application (in Russian lang. Windows) is not unicode-ready.
Re: dub can't read files from cache
On Thu, 18 Sep 2014 15:53:02 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Seriously, console application (in Russian lang. Windows) is not unicode-ready. that's 'cause authors tend to ignore W-functions. but GNU/Linux is not better, 'cause authors tend to ignore any encodings except latin1 and utf-8. koi? what is koi? it's broken utf-8, we don't know about koi! and we don't care what your locale says, it's utf-8! bwah, D compiler does just that. signature.asc Description: PGP signature
Re: dub can't read files from cache
On Thursday, 18 September 2014 at 16:05:15 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 18 Sep 2014 15:53:02 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Seriously, console application (in Russian lang. Windows) is not unicode-ready. that's 'cause authors tend to ignore W-functions. but GNU/Linux is not better, 'cause authors tend to ignore any encodings except latin1 and utf-8. koi? what is koi? it's broken utf-8, we don't know about koi! and we don't care what your locale says, it's utf-8! bwah, D compiler does just that. You can choice encoding for console in Linux and edit encoding for other files with different utilities. https://plus.google.com/u/0/photos/110121926948523695249/albums/6060444524608761937/6060444528078004690?pid=6060444528078004690oid=110121926948523695249
Re: dub can't read files from cache
On Thursday, 18 September 2014 at 16:05:15 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 18 Sep 2014 15:53:02 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Seriously, console application (in Russian lang. Windows) is not unicode-ready. that's 'cause authors tend to ignore W-functions. but GNU/Linux is not better, 'cause authors tend to ignore any encodings except latin1 and utf-8. koi? what is koi? it's broken utf-8, we don't know about koi! and we don't care what your locale says, it's utf-8! bwah, D compiler does just that. one ring to rule them all UTF-8 = Lord of the encodings.
Re: dub can't read files from cache
On Thursday, 18 September 2014 at 16:05:15 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 18 Sep 2014 15:53:02 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Seriously, console application (in Russian lang. Windows) is not unicode-ready. that's 'cause authors tend to ignore W-functions. but GNU/Linux is not better, 'cause authors tend to ignore any encodings except latin1 and utf-8. koi? what is koi? it's broken utf-8, we don't know about koi! and we don't care what your locale says, it's utf-8! bwah, D compiler does just that. one ring to rule them all UTF-8 = Lord of the encodings.
Re: Interop with C++ library - what toolchain do you use?
On Thursday, 18 September 2014 at 08:27:07 UTC, Szymon Gatner wrote: On Wednesday, 17 September 2014 at 22:28:44 UTC, Cliff wrote: So I am trying to use a C++ library with D. My toolchain is currently Visual Studio 2013 with Visual D, using the DMD compiler. When trying to link, I obviously ran into the OMF vs. COFF issue, which makes using the C++ library a bit of a trial to say the least (I played around with some lib format converters but perhaps unsurprisingly this led to somewhat unpredictable behavior.) I'd like to fix up my toolchain to avoid having this issue. For those of you who are on Windows and who do D and C++ interop, what toolchain have you had success with? Additionally, I have heard tell that D now allows calling C++ non-virtual class methods but I have not found documentation on how to make this work (how do I define the C++ class layout in D - I know how to do it for vtable entries but not non-virtual methods.) Pointers to docs or samples would be much appreciated. Thanks! I am using Visual Studio 2012 (in x64 bit mode that is). Binary D distribution also comes with phobos64.lib that C++ executable has to link. With VisualD plugin you can just add D static library project to the solution and the link C++ exe to it. It is very easy to make back-and-forth function calls between C++/D. I recommend Adam Ruppe's excellent D Cookbook Integration chapter on the details on how to expose this for cross-lang usage. It does not all work correctly tho. I reported my issues on learn subforum but didn't get much help. In short: it seems not everything in D run-time (Phobos) gets properly initialized even after successful rt_init() call. In my case simple call to writeln() causes a crash because stdout is not properly initialized on D'd side. Happy hybridizing! Thanks guys. I do have that book, but I was unaware of the COFF capabilities of the 64-bit DMD, I'll take a look at it.
Re: dub can't read files from cache
On Thu, 18 Sep 2014 16:31:08 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: one ring to rule them all UTF-8 = Lord of the encodings. i want 42th symbol from the string. what? what do you mean saying that i must scan the whole string from the beginning to get it? oh, High Lord, this one Lord is fake! signature.asc Description: PGP signature
Re: dub can't read files from cache
On Thu, 18 Sep 2014 16:24:17 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You can choice encoding for console in Linux yes. and i chose koi8. yet many utilities tend to ignore my locale when reading files (hey, D compiler, i'm talking about you!). i don't care about localized messages (i'm using English messages anyway), but trying to tell me that my text file is invalid utf-8, or my filename is invalid utf-8, or spitting utf-8 encoded messages to my terminal drives me mad. what is so wrong with locale detection that virtually nobody does that? we have iconv, it's readily available on any decent GNU/Linux platform, yet it's still so hard to detect that stinky locale and convert that stinky utf-8 to it? BS. (hey, phobos, i'm talking about your stdout.write() here too!) the whole utf-8 or die attitude has something very wrong in it. signature.asc Description: PGP signature
Re: dub can't read files from cache
On Thursday, 18 September 2014 at 16:51:06 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 18 Sep 2014 16:31:08 + Ilya Yaroshenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: one ring to rule them all UTF-8 = Lord of the encodings. i want 42th symbol from the string. what? what do you mean saying that i must scan the whole string from the beginning to get it? oh, High Lord, this one Lord is fake! That's why a while ago I was considering convert a string from UTF-8 to UTF-32. UTF-32 is nice I don't understand when people say there are no any advantage to use it. Indexing is just possible. Memory size isn't much an issue. I needed to extend support for UTF-8 in a program where I had some routines where I could move forward and backward very easily just indexing but using UTF-8 it isn't possible so I needed to make my own an iterator when I need to save a pointer instead of a index. In memory usage it isn't so bad since a size of that index is same as pointer but the structure of the program was a bit ugly, a kind of hack, IMHO.
