Re: D/Objective-C 64bit
I would expect to be using an ObjcObject instead of an
NSObject here,
but this does not compile. The signature of the target action
seems to
be irrelevant, it may have no or more parameters. I guess this
is just
ok and the expected behavior.
Hmm, that sounds strange. What exact errors do you get?
source/appdelegate.d(47): Error: function
appkit.tableview.NSTableView.setDoubleAction (objc_selector*
aSelector) is not callable using argument types (extern
(Objective-C) void __selector(ObjcObject))
Line 46 47:
auto doubleAction = AppDelegate.doubleClickAction ;
demoTableView.setDoubleAction(doubleAction) ;
Line 80:
void doubleClickAction(ObjcObject sender) {
actually, when line 46 47 are like above, it doesn't matter if
I change ObjcObject to NSObject, but I guess my problem here is
how Map the function in tableview.d:
void setDoubleAction(objc.runtime.SEL aSelector)
[setDoubleAction:] ;
[1]
https://github.com/jacob-carlborg/dmd/blob/d-objc/test/runnable/objc/objc_selector.d
I know Dip 43 almost by heart now, but I haven't yet discovered
the tests you wrote. Nice, this will be extremely helpful.
Best!
Re: D/Objective-C 64bit
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
This should be the way to do it. Now in the implementation of the
action:
void doubleClickAction(ObjcObject sender) {
NSLog(double click action) ;
NSLog(the sender: %@, sender) ;
}
This works fine and prints the log: 2014-11-04 10:01:57.967
tableview[9988:507] the sender: NSTableView: 0x7f8309f156b0
But now I would like to do something with this sender, like I do
often in an Objective-C project:
NSTableView tableView = cast(NSTableView)sender ;
I get a EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
replace both ObjcObject with NSObject (in tableview.d, the
mapping, and the target action) this cast works. I might be
missing something obvious here.
Thanks again.
Re: D/Objective-C 64bit
what is funky in this context (see above): even when using
ObjcObject in both the mapping and the action method, the test
if (sender is demoTableView) {
//
}
does not fail in the action, only a cast to a NSTableView object
fails. Of course, in this setting it's not really a problem, I
can work directly on the demoTableView member and can forget
about the sender, but this is against how I would do it in
Objective-C where I can always cast an id reference to the
expected type.
Re: dfl2 is comming
I found build tool named dco. Could you explain were it can be helpful?
Re: dfl2 is comming
will it work for 64bit? On Saturday, 18 October 2014 at 14:39:05 UTC, FrankLike wrote: There were 15 forks of DFL on github (some of them working fine with 2.066), you made a 16nth, with another name. ;) What's the point? Btw, your version (just like most others) contains bugs causing the app to crash on exit. The issue is with destructors (in Timer and Tooltip, for example) that try to access some global/static variables, and when the app closes GC does its final cycle and calls destructors, and at this time many of those objects are already dead. It went silent in older versions of D, but since 2.065 was pretty visible. My fix is here: https://github.com/thedeemon/dfl/commit/290d6456f6d13447311845929fd929acb6938a5d (sadly, combined with additional changes I made when trying to find the bugs) Sorry,D2.066 is no 'dm' folder,its libs all moved in dmd2\windows\lib,and most new users like to use the 'dub' or Visual studio .net . A few minutes ago,I test to compile the dfl which was cloned from 'https://github.com/Rayerd/dfl',but found some errors,not get the *.objs,and must modify the bat file. Now,it's a important thing, let more new users to like the dfl in their ways:'dub' or Visual studio.net. I think its very easy to use it for you. Thank you very much.
Re: D/Objective-C 64bit
On 2014-11-04 09:07:08 +, Christian Schneider
schnei...@gerzonic.net said:
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
That's indeed the best way to do it.
This should be the way to do it. Now in the implementation of the
action:
void doubleClickAction(ObjcObject sender) {
NSLog(double click action) ;
NSLog(the sender: %@, sender) ;
}
This works fine and prints the log: 2014-11-04 10:01:57.967
tableview[9988:507] the sender: NSTableView: 0x7f8309f156b0
But now I would like to do something with this sender, like I do
often in an Objective-C project:
NSTableView tableView = cast(NSTableView)sender ;
I get a EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
replace both ObjcObject with NSObject (in tableview.d, the
mapping, and the target action) this cast works. I might be
missing something obvious here.
There is no test for interface-to-class casts in the D/Objective-C test
suite, which means you're likely the first person to try that. It's
probably just an oversight in the compiler code.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-01 10:47:54 +, Jacob Carlborg d...@me.com said: On 2014-11-01 01:58, Michel Fortin wrote: That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or this.class to get the metaclass) this.class could perhaps be called this.classof, at least that's valid syntax. Although I don't know what to do about __selector. Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-04 13:29, Christian Schneider wrote:
what is funky in this context (see above): even when using
ObjcObject in both the mapping and the action method, the test
if (sender is demoTableView) {
//
}
does not fail in the action
That will just compare the address of the objects.
, only a cast to a NSTableView object
fails. Of course, in this setting it's not really a problem, I
can work directly on the demoTableView member and can forget
about the sender, but this is against how I would do it in
Objective-C where I can always cast an id reference to the
expected type.
See the reply by Michel. It's probably a bug/oversight in the compiler.
As a workaround you can, as you said, use NSObject instead of ObjcObject
in both places.
What happens if you declare doubleClickAction like this:
void doubleClickAction(NSTableView sender) { ... }
That will probably require a cast when passing the selector to
setDoubleAction.
--
/Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-04 23:46, Michel Fortin wrote: Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. Yeah, that would be preferable. I would like to avoid the mess that the migration from D1 to D2 caused. Where if one wanted to support both some D2 code needed to be in a string mixin guarded with a version block. -- /Jacob Carlborg
Re: D/Objective-C 64bit
There is no test for interface-to-class casts in the D/Objective-C test suite, which means you're likely the first person to try that. It's probably just an oversight in the compiler code. Hey Michel, thanks very much for this explanation! That's actually good news. It certainly will be good to have this fixed, as the target action mechanism gets a lot of it's spice that the sender only needs to comply to a protocol and can be whatever control or even nil. Best! Christian
Re: Programming Language for Games, part 3
On 2014-11-01 12:31, bearophile wrote:
Third part of the A Programming Language for Games, by Jonathan Blow:
https://www.youtube.com/watch?v=UTqZNujQOlA
Discussions:
http://www.reddit.com/r/programming/comments/2kxi89/jonathan_blow_a_programming_language_for_games/
His language seems to disallow comparisons of different types:
void main() {
int x = 10;
assert(x == 10.0); // Refused.
}
I like the part about compile-time tests for printf:
http://youtu.be/UTqZNujQOlA?t=38m6s
The same strategy is used to validate game data statically:
http://youtu.be/UTqZNujQOlA?t=55m12s
A screenshot for the printf case:
http://oi57.tinypic.com/2m5b680.jpg
He writes a function that is called to verify at compile-time the
arguments of another function. This does the same I am asking for a
static precondition, but it has some disadvantages and advantages. One
advantage is that the testing function doesn't need to be in the same
module as the function, unlike static enums. So you can have the
function compiled (separated compilation). Perhaps it's time for DIP.
LLVM has a JIT compiler, LDC uses LLVM. Perhaps time to see if it's
possible to use the JIT compiler for CTFE.
--
/Jacob Carlborg
Re: Programming Language for Games, part 3
On Tuesday, 4 November 2014 at 08:26:36 UTC, Jacob Carlborg wrote: LLVM has a JIT compiler, LDC uses LLVM. Perhaps time to see if it's possible to use the JIT compiler for CTFE. Isn't SDC already able to do JIT compilation for CTFE? I swear I've seen Deadalnix mention it before...
Re: bug in assigning to dynamic array element
On Tuesday, 4 November 2014 at 01:52:00 UTC, ketmar via Digitalmars-d wrote: sure, this decision will break some code. that's why it will never be approved, despite all hype about safety. at least leaving this feature as is should help C++ programmers to adopt D. they used to languages that has nothing common with sanity. ;-) Yes… http://en.wikipedia.org/wiki/Sequence_point http://dlang.org/expression D needs a major overhaul: 1. assigns should not be expressions, but statements 2. assign should be a sequence point, not UB. 3. re-allocation should always be explicit in non-library types. Solves all issues.
Is this a bug? `static if` fails silently.
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, test);
this(T t)
{
this.t = t;
}
}
}
void main()
{
//Nothing is printed
Test!int t;
}
Didn't this code used to failed at the point of `typeof(T)`? Has
this changed since previous releases?
Re: Is this a bug? `static if` fails silently.
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, test);
this(T t)
{
this.t = t;
}
}
}
void main()
{
//Nothing is printed
Test!int t;
}
Didn't this code used to failed at the point of `typeof(T)`?
Has this changed since previous releases?
It is not static if, it is is. Is is defined as false for invalid
types.
Re: Is this a bug? `static if` fails silently.
On Tuesday, 4 November 2014 at 09:07:10 UTC, deadalnix wrote: It is not static if, it is is. Is is defined as false for invalid types. Ah, right. That's annoyingly hard to spot, but it is not a bug I suppose.
Re: Programming Language for Games, part 3
On Tuesday, 4 November 2014 at 08:48:13 UTC, Meta wrote: On Tuesday, 4 November 2014 at 08:26:36 UTC, Jacob Carlborg wrote: LLVM has a JIT compiler, LDC uses LLVM. Perhaps time to see if it's possible to use the JIT compiler for CTFE. Isn't SDC already able to do JIT compilation for CTFE? I swear I've seen Deadalnix mention it before... Yes, SDC use LLVM's JIT capability to do CTFE.
Re: Is this a bug? `static if` fails silently.
On Tuesday, 4 November 2014 at 09:07:10 UTC, deadalnix wrote:
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, test);
this(T t)
{
this.t = t;
}
}
}
void main()
{
//Nothing is printed
Test!int t;
}
Didn't this code used to failed at the point of `typeof(T)`?
Has this changed since previous releases?
It is not static if, it is is. Is is defined as false for
invalid types.
a std.traits.TypeOf that errors out on non-types would be nice.
Re: Is this a bug? `static if` fails silently.
On Tuesday, 4 November 2014 at 09:54:44 UTC, John Colvin wrote:
On Tuesday, 4 November 2014 at 09:07:10 UTC, deadalnix wrote:
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, test);
this(T t)
{
this.t = t;
}
}
}
void main()
{
//Nothing is printed
Test!int t;
}
Didn't this code used to failed at the point of `typeof(T)`?
Has this changed since previous releases?
It is not static if, it is is. Is is defined as false for
invalid types.
a std.traits.TypeOf that errors out on non-types would be nice.
woops, ignore me.
Re: The cost of write barriers
On Tuesday, 4 November 2014 at 06:09:21 UTC, deadalnix wrote: Write barrier are only required on objects that contain mutable pointer and are shared. Required for what exactly? If you want generational GC, you'll need barriers everywhere, not only in shared heap.
Re: The cost of write barriers
On Monday, 3 November 2014 at 11:50:57 UTC, thedeemon wrote: Btw, how are write barriers implemented in Go now? It seems it's actually currently just a functional call[1], to simulate the performance cost of a write barrier. This is to smooth out the performance drop across multiple releases, rather than a single release bearing the full brunt of the write barrier's introduction. 1.https://code.google.com/p/go/source/browse/src/runtime/mgc0.go?name=defaultr=f98b2e08a26867096c2dc78c5283097effcfa0ec#86 On Tuesday, 4 November 2014 at 06:09:21 UTC, deadalnix wrote: Write barrier are only required on objects that contain mutable pointer and are shared. in D, that is a subset of the shared heap. D's type system would allow to use such strategy while mitigating the cost quite a lot. Are there plans to take advantage of this? I've lost track of where the current GC effort is heading; is it focused on integrating the recent D2 port of that parallel collector, or on improving the current collector, or on pervasive reference counting?
Re: Programming Language for Games, part 3
On Tuesday, 4 November 2014 at 00:51:10 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Nov 03, 2014 at 04:29:17PM -0800, Walter Bright via
Digitalmars-d wrote:
On 11/3/2014 10:03 AM, Nick Treleaven wrote:
On 02/11/2014 20:33, Walter Bright wrote:
It's simply not workable to put a wall between them. Every
proposal
for it has entailed various unfortunate, ugly, and arbitrary
consequences.
We need warnings like gcc has:
-Wsign-compare
Warn when a comparison between signed and unsigned
values could
produce an incorrect result when the signed value is
converted
to unsigned.
-Wconversion
Warn for implicit conversions that may alter a value.
This
includes ... conversions between signed and unsigned,
like
unsigned ui = -1 ... Warnings about conversions between
signed
and unsigned integers can be disabled by using
-Wno-sign-conversion.
I find these to suffer from the same problems as all the
proposals to
fix the issue - they motivate the user to fix them with
unfortunate, ugly, and arbitrary consequences.
We need to be very careful with the idea of just add a
warning.
Warnings are a sure sign of wishy-washy language design where
the
designers cannot make up their mind, so they dump it on the
user. One
person's warning become another person's must fix, and the
language
becomes balkanized, which is not good for portability,
comprehensibility, and best practices.
[...]
Don't add a warning, just make it outright illegal to assign
signed to
unsigned and vice versa unless an explicit cast is given. Code
that
*needs* to assign signed to unsigned *should* be
self-documented with a
cast indicating a reinterpretation of the bit representation of
the
value, and code that *unintentionally* mixes signs is buggy and
therefore *should* result in a compile error so that the
programmer can
fix the problem.
There are no unfortunate, ugly, or arbitrary consequences
here.
Much like the recent (or not-so-recent) change of prohibiting
implicit
conversion of a pointer to bool in an if-condition, or the
requirement
of a default case in a non-final switch, or so many other
improvements
in D over C/C++, such a change will (1) make problematic code
an error
so that it will get fixed, and (2) force users to rewrite
non-problematic code to be more self-documenting so that their
intent is
clearer. Sounds like a win-win situation to me.
Simply change the comparison to something that always works:
/// Returns negative value if a b, 0 if they are equal or
positive value if a b.
/// This will always yield a correct result, no matter which
integral types are compared.
/// It uses one extra comparison operation if and only if
/// one type is signed and the other unsigned but has bigger max.
/// For comparison with floating point values the buildin
/// operations have no problem, so we don't handle them here.
C opCmp(T, U)(const(T) a, const(U) b) pure @safe @nogc nothrow
if(isIntegral!T isIntegral!U)
{
alias Signed!CommonType!(T, U) C;
static if(isSigned!T isUnsigned!U T.sizeof = U.sizeof)
{
return (b cast(U)T.max) ? -1 : cast(C)a - cast(C)b;
}
else static if(isUnsigned!T isSigned!U T.sizeof =
U.sizeof)
{
return (a cast(T)U.max) ? 1 : cast(C)a - cast(C)b;
}
else // both signed or both unsigned or the unsigned type is
smaller and can therefore be safely cast to the signed type
{
return cast(C)a - cast(C)b;
}
}
Re: Programming Language for Games, part 3
On Sunday, 2 November 2014 at 18:04:18 UTC, Ary Borenszweig wrote: About the bytecode he generates: as someone said in the reddit discussion, having to maintain two separate language implementations (compiled and interpreted) can lead to small and subtle bugs. And, running code via an intepreter is slower than compiled code, even if the interpreter is really good. So I don't think the bytecode stuff is a really good idea. Well, D maintains several implementations (interpreter for CTFE and the backends), and the interpreter doesn't even use byte code so it's probably even slower. Is it really a problem? Sometimes, probably, but not too often.
Re: Fwd: Interfacing with C++
On 11/4/14, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Now from the http://dlang.org/cpp_interface I find out the current status of built-in C++ interfacing support. I'm working on Linux so using the COM support is not an option for me (whatever COM may be!). That page is out of date. Support has improved significantly since then. 2) Is there any further work underway to implement support for static and non-virtual class member functions? Or is this not at all possible? If so, why? Work is complete. IIRC it was in the last release, you might need to grab master/an alpha for very latest stuff. Special member functions (dtor/operators) generally don't work. So I'm using latest dmd 2.066.1 on an i386 machine. Does it have the latest functionality which you refer to? And what is the syntax to support static and non-virtual member functions? Thanks! -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Programming Language for Games, part 3
Am Mon, 03 Nov 2014 16:29:17 -0800 schrieb Walter Bright newshou...@digitalmars.com: On 11/3/2014 10:03 AM, Nick Treleaven wrote: On 02/11/2014 20:33, Walter Bright wrote: It's simply not workable to put a wall between them. Every proposal for it has entailed various unfortunate, ugly, and arbitrary consequences. We need warnings like gcc has: -Wsign-compare Warn when a comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned. -Wconversion Warn for implicit conversions that may alter a value. This includes ... conversions between signed and unsigned, like unsigned ui = -1 ... Warnings about conversions between signed and unsigned integers can be disabled by using -Wno-sign-conversion. I find these to suffer from the same problems as all the proposals to fix the issue - they motivate the user to fix them with unfortunate, ugly, and arbitrary consequences. We need to be very careful with the idea of just add a warning. Warnings are a sure sign of wishy-washy language design where the designers cannot make up their mind, so they dump it on the user. One person's warning become another person's must fix, and the language becomes balkanized, which is not good for portability, comprehensibility, and best practices. Although I might agree that warnings can indicate 'wishy-washy language design' you can not simply assume the reverse/negation. There's obviously a problem and just 'not adding warnings' doesn't magically solve this 'wishy-washy language design' issue. And as long as there is no other solution warnings are better than simply ignoring the problem. But I think it's likely this check will be implemented in Dscanner (https://github.com/Hackerpilot/Dscanner/issues/204) and in the end it doesn't really matter where it's implemented.
Library inheritance
Hi, just wondering if it's possible, due to the lag of header files, to inherit from some class that exists within a library, that has been written in D? How did you solve that? Thanks in advance.
Re: Library inheritance
A library may provide header files for this, or you can just use the source code itself to import and inherit from.
Template Instantiation Bug
In the past I don't get much response when I file a bug in
BugZilla so I wanted to see if anyone could tell me anything
about this issue in the forums.
I believe a bug has already been created here:
https://issues.dlang.org/show_bug.cgi?id=2372
Here's the code to reproduce it:
--
import std.stdio;
template Transform(T)
{
alias Transform = T;
}
void testTransform(T)(Transform!T t)
{
}
void testNoTransform(T)(T t)
{
}
void main(string[] args)
{
testTransform(3); // FAILS cannot deduce function...
testTransform!int(3);
testNoTransform(3);
testNoTransform!int(3);
}
--
The test(3) line fails with this error message:
main.d(15): Error: template main.testTransform cannot deduce
function from argument types !()(int), candidates are:
main.d(7):main.testTransform(T)(Transform!T t)
Does anyone know anything about this, maybe this is as
designed? Thanks in advance for the info.
Re: Fwd: Interfacing with C++
Static functions correspond to static D functions. Non-virtual functions are struct methods and final class methods.
Re: Template Instantiation Bug
On 11/4/14 11:01 AM, Jonathan Marler wrote:
In the past I don't get much response when I file a bug in BugZilla so I
wanted to see if anyone could tell me anything about this issue in the
forums.
I believe a bug has already been created here:
https://issues.dlang.org/show_bug.cgi?id=2372
Here's the code to reproduce it:
--
import std.stdio;
template Transform(T)
{
alias Transform = T;
}
void testTransform(T)(Transform!T t)
{
}
void testNoTransform(T)(T t)
{
}
void main(string[] args)
{
testTransform(3); // FAILS cannot deduce function...
testTransform!int(3);
testNoTransform(3);
testNoTransform!int(3);
}
--
The test(3) line fails with this error message:
main.d(15): Error: template main.testTransform cannot deduce function
from argument types !()(int), candidates are:
main.d(7):main.testTransform(T)(Transform!T t)
Does anyone know anything about this, maybe this is as designed?
Thanks in advance for the info.
This is as designed.
The reason is because the compiler cannot deduce *backwards* how to
instantiate a template to get the right result.
I ran into this a long time ago when porting Tango.
Here is the counter-case:
template Transform(T)
{
static if(is(T == string)) alias Transform = int;
else static if(is(T == int)) alias Transform = string;
else alias Transform = T;
}
Basically, the compiler has to figure out how to instantiate Transform
in order for it to result in an int. While it's easy for us to see what
it needs to do, it doesn't have that capability.
People have argued in the past that anything with a simple alias should
be doable. I don't know if that's true or not, but I don't think it
works today. There may be a bug report somewhere on it, I didn't search.
The bug you found is not it.
-Steve
Re: Programming Language for Games, part 3
On 2014-11-04 10:08, deadalnix wrote: Yes, SDC use LLVM's JIT capability to do CTFE. Can't it access parts of the system that DMD's CTFE cannot? -- /Jacob Carlborg
Re: Programming Language for Games, part 3
On 2014-11-04 09:48, Meta wrote: Isn't SDC already able to do JIT compilation for CTFE? I swear I've seen Deadalnix mention it before... Forgot about that. -- /Jacob Carlborg
Re: Template Instantiation Bug
On Tuesday, 4 November 2014 at 16:55:10 UTC, Steven Schveighoffer
wrote:
This is as designed.
The reason is because the compiler cannot deduce *backwards*
how to instantiate a template to get the right result.
I ran into this a long time ago when porting Tango.
Here is the counter-case:
template Transform(T)
{
static if(is(T == string)) alias Transform = int;
else static if(is(T == int)) alias Transform = string;
else alias Transform = T;
}
Basically, the compiler has to figure out how to instantiate
Transform in order for it to result in an int. While it's easy
for us to see what it needs to do, it doesn't have that
capability.
Ah I see now. After reading your comment I had to walk through
how the compiler works out the types but after doing so it makes
sense. I've included my thoughts to aid any others with the same
question.
Given a template signature like this:
void mytemplate(T)(T t)
Whenever a call to the template does not specify the template
parameter T, the compiler needs to be able to deduce the type
of T. In the example given above, T is equal to the type of the
first argument typeof(t).
If you were to apply some type of transformation to the argument,
then the compiler cannot deduce T because it cannot reverse the
transformation. For example, if you had the following type
transformation:
template Transform(T)
{
alias Transform = T;
}
The compiler does not know how to reverse this template,
meaning, given the output of Transform, the compiler cannot
deduce what the input of Transform was EVEN IF THE TEMPLATE IS AS
SIMPLE AS THIS ONE.
I hope this helps for anybody else with the same question.
Re: Template Instantiation Bug
Steven Schveighoffer wrote in message news:m3b0dd$6e0$1...@digitalmars.com... People have argued in the past that anything with a simple alias should be doable. I don't know if that's true or not, but I don't think it works today. There may be a bug report somewhere on it, I didn't search. The bug you found is not it. https://issues.dlang.org/show_bug.cgi?id=1807
Does search work at all in forum?
I don't remember anytime the search box of forum worked at all. All pages load really quickly, but when I want to search anything, it waits for a while (Firefox indicates something request is going), then stop, and nothing happens. Example I would search for without phobos. While writing this post, I did it again, and nothing. Is it operational?
Re: Template Instantiation Bug
On 11/4/14 1:05 PM, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:m3b0dd$6e0$1...@digitalmars.com... People have argued in the past that anything with a simple alias should be doable. I don't know if that's true or not, but I don't think it works today. There may be a bug report somewhere on it, I didn't search. The bug you found is not it. https://issues.dlang.org/show_bug.cgi?id=1807 Hm.. interesting to note that Martin's suggestion has come to fruition, might this be revisited? -Steve
Re: Does search work at all in forum?
On 11/04/2014 11:11 AM, tcak wrote: I don't remember anytime the search box of forum worked at all. All pages load really quickly, but when I want to search anything, it waits for a while (Firefox indicates something request is going), then stop, and nothing happens. Example I would search for without phobos. While writing this post, I did it again, and nothing. Is it operational? Works fine as I write this. The search is dispatched to Google's following URL: https://www.google.com/search?q=without+phobossubmit.x=11submit.y=9domains=dlang.orgsourceid=google-searchsitesearch=forum.dlang.orggws_rd=ssl Ali
Re: Is this a bug? `static if` fails silently.
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote: typeof(T) What is the type of a type?
The D Programming Language: Getting Started event
(a bit late) A nice initiative to promote the D programming language: http://bucharest.techhub.com/events/the-d-programming-language-getting-started- Kudos to AA.
Re: The D Programming Language: Getting Started event
On Tuesday, 4 November 2014 at 21:39:12 UTC, nemo wrote: (a bit late) A nice initiative to promote the D programming language: http://bucharest.techhub.com/events/the-d-programming-language-getting-started- Kudos to AA. And, for speakers of the language, the story of it: http://adevarul.ro/tech/internet/facebook-utilizeaza-limbaj-programare-inventat-romanul-andrei-alexandrescu-1_54587eea0d133766a884a83b/index.html
Re: Template Instantiation Bug
On 11/4/2014 9:51 AM, Jonathan Marler wrote: given the output of Transform, the compiler cannot deduce what the input of Transform was EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE. To answer a question not asked, why doesn't the compiler see the simple case and handle it? The problem is that this becomes a special case in the language specification, making the language harder to understand. Cue bug reports of people confused about why the simpler cases work and the more complex ones do not, and they overall get a negative impression of the language. And I don't blame them.
Re: The cost of write barriers
On Tuesday, 4 November 2014 at 10:09:47 UTC, thedeemon wrote: On Tuesday, 4 November 2014 at 06:09:21 UTC, deadalnix wrote: Write barrier are only required on objects that contain mutable pointer and are shared. Required for what exactly? If you want generational GC, you'll need barriers everywhere, not only in shared heap. Ok I see, I was think about write barrier for concurrent collection. Sorry for the confusion.
Re: Programming Language for Games, part 3
On Tuesday, 4 November 2014 at 17:18:25 UTC, Jacob Carlborg wrote: On 2014-11-04 10:08, deadalnix wrote: Yes, SDC use LLVM's JIT capability to do CTFE. Can't it access parts of the system that DMD's CTFE cannot? Yes, I have yet to implement a check for ctfeability.
Re: Is this a bug? `static if` fails silently.
On Tuesday, 4 November 2014 at 21:20:59 UTC, Tofu Ninja wrote: On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote: typeof(T) What is the type of a type? A kind, of course. =)
Re: The D Programming Language: Getting Started event
On 11/04/2014 01:39 PM, nemo wrote: (a bit late) A nice initiative to promote the D programming language: http://bucharest.techhub.com/events/the-d-programming-language-getting-started- Bad link or not public yet? Ali
Re: The D Programming Language: Getting Started event
On 11/04/2014 02:46 PM, Ali Çehreli wrote: On 11/04/2014 01:39 PM, nemo wrote: (a bit late) A nice initiative to promote the D programming language: http://bucharest.techhub.com/events/the-d-programming-language-getting-started- Bad link or not public yet? Ali I think that was my Thunderbird of Firefox removing the dash at the end of the link. It is required. :) Ali
Re: Template Instantiation Bug
On Tuesday, 4 November 2014 at 21:48:29 UTC, Walter Bright wrote:
On 11/4/2014 9:51 AM, Jonathan Marler wrote:
given the
output of Transform, the compiler cannot deduce what the input
of Transform was
EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE.
To answer a question not asked, why doesn't the compiler see
the simple case and handle it?
The problem is that this becomes a special case in the language
specification, making the language harder to understand. Cue
bug reports of people confused about why the simpler cases work
and the more complex ones do not, and they overall get a
negative impression of the language. And I don't blame them.
Yes, trying to reverse the logic inside a template in the GENERAL
case would likely be next to impossible, or at least, require
alot of work/code to support something thay may not be very
useful. And if you can't solve the general case, I agree you
shouldn't support the simple cases.
However, I'll bring up the reason I wanted this functionality in
case you have another solution. I wanted to create a template
that used different parameter attributes depending on the type.
For example, I just submitted a pull request to phobos to
optimize the put/doPut functions in std.range
(https://github.com/D-Programming-Language/phobos/pull/2655) to
only use ref OutputRange when necessary. For types like
pointers, classes, delegates, and functions, the ref attribute is
unnecessary and can inhibit compiler optimization. For my pull
request, the only solution I could come up with was to have 2
instances of each function with a template guard that handles ref
and non-ref paramters:
private template isPassByValue(T)
{
enum bool isPassByValue =
isPointer!T ||
is( T == class ) ||
is( T == delegate ) ||
is( T == function ) ;
}
void put(R, E)(R r, E e) if( isPassByValue!R )
{
// put code
}
void put(R, E)(ref R r, E e) if( !isPassByValue!R )
{
// exact same put code
}
There's got to be a better way to do this. If anyone has any
ideas let me know.
Compiling druntime gives error messages
I have DMD 2.066.1 installed on 64-bit Ubuntu 14.04.
I downloaded all files from
https://github.com/D-Programming-Language/druntime
I use following command line to compile druntime to
generate library.
make -f posix.mak DMD=dmd
First few lines are as follows:
dmd -c -o- -Isrc -Iimport -Hfimport/core/sync/barrier.di
src/core/sync/barrier.d
src/core/stdc/stdio.d(859): Error: found 'nothrow' when expecting
'{'
src/core/stdc/stdio.d(861): Error: mismatched number of curly
brackets
src/core/stdc/stdio.d(862): Error: mismatched number of curly
brackets
src/core/stdc/stdio.d(863): Error: mismatched number of curly
brackets
Then I opened both
./src/core/stdc/stdio.d
/usr/include/dmd/druntime/import/core/stdc/stdio.d
to compare them each other.
On line 859, the downloaded stdio.d has asm nothrow @nogc.
The installed stdio.d has asm only.
Am I downloading wrong druntime codes, or using wrong DMD
compiler? It is like downloaded druntime codes are coming from
future.
Re: Compiling druntime gives error messages
On Tue, Nov 04, 2014 at 11:32:34PM +, tcak via Digitalmars-d wrote: I have DMD 2.066.1 installed on 64-bit Ubuntu 14.04. I downloaded all files from https://github.com/D-Programming-Language/druntime [...] Am I downloading wrong druntime codes, or using wrong DMD compiler? It is like downloaded druntime codes are coming from future. Generally, to compile druntime from git HEAD requires that you use dmd from git HEAD, as a number of compiler / druntime fixes require changes in both. So it's not surprising if the latest druntime fails to be compiled by an earlier compiler. See also: http://wiki.dlang.org/Building_DMD (which includes building druntime). T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Re: sortOn: sorts range of aggregates by member name(s)
On Wednesday, 5 November 2014 at 00:32:32 UTC, Nordlöw wrote:
Has there been any proposals to add a sort-wrapper, say sortBy,
in cases such as
struct X { double x, y, z; }
auto r = new X[3];
used as
r.sortBy!(x, y)
sorting r by value of x then y.
If not and anybody is interest I could write one and make PR in
std.algorithm.
I think you're looking for multiSort.
http://dlang.org/phobos/std_algorithm.html#.multiSort
sortOn: sorts range of aggregates by member name(s)
Has there been any proposals to add a sort-wrapper, say sortBy,
in cases such as
struct X { double x, y, z; }
auto r = new X[3];
used as
r.sortBy!(x, y)
sorting r by value of x then y.
If not and anybody is interest I could write one and make PR in
std.algorithm.
Re: Compiling druntime gives error messages
On Tuesday, 4 November 2014 at 23:45:54 UTC, H. S. Teoh via Digitalmars-d wrote: On Tue, Nov 04, 2014 at 11:32:34PM +, tcak via Digitalmars-d wrote: I have DMD 2.066.1 installed on 64-bit Ubuntu 14.04. I downloaded all files from https://github.com/D-Programming-Language/druntime [...] Am I downloading wrong druntime codes, or using wrong DMD compiler? It is like downloaded druntime codes are coming from future. Generally, to compile druntime from git HEAD requires that you use dmd from git HEAD, as a number of compiler / druntime fixes require changes in both. So it's not surprising if the latest druntime fails to be compiled by an earlier compiler. See also: http://wiki.dlang.org/Building_DMD (which includes building druntime). Specifically, it was noticed that certain function attribute checks are skipped if the function contains an asm block (https://issues.dlang.org/show_bug.cgi?id=12979), so attributes for asm blocks were added after the stable release: https://github.com/D-Programming-Language/dmd/pull/4033 Obviously, the stable compiler doesn't recognize those subsequent changes in git HEAD, so you have to compile dmd from git source if you want to compile druntime from the latest git.
GSOC Summer 2015 - Second call for Proposals
This is my second Call for Proposals for the 2015 Google Summer of Code. Anyone interested in mentoring, or who has good idea's for a project for 2015 please post here. So far I have the following people who have expressed interest in mentoring: Mentor's with specific projects in mind: Mentor Project Area(s) Amaury Sechet (Deadalnix): SDC - D Compiler as a library Martin Nowak ARM Support and Bare Metal D Iain BuclawGDC I have a pretty good set of specific idea's from Deadalnix, but I could use more specific project ideas for Martin and Iain. A few others have volunteered to mentor, and have given general areas of interest, but I don't really have specific project suggestions from: Andrei Alexandrescu Phobos Rikki Cattermole Web Development Russel Winder Phobos/QML: std.parallelism, std.benchmark Jacob Ovrum std.i18n Jens Mueller std.socket, std.log, std.benchmark, std.numeric.matrix Project Ideas (Without a Mentor) boost::log boost::program_options A parser generator on par with antlr4 std.stream replacement / buffers std.xml SSL implementation D Game? on Mobile platforms Improved Garbage Collection (improve compare existing efforts) Move some code.dlang.org libs into std.experimental std.event (working with fibers) std.fiber D message passing across processes (openmp) OGI for D Support for paths in string imports on Windows Automatic Reference Counting Finish export/shared std.smid into review queue vibe.d (regenerate templates without full recompilation) D to JS compiler DDL for D2 A few other questions for the community (and possible mentors). 1. I was thinking that as a way of making our idea's/mentor's lists to stand out I would like to post short Bio's on each mentor - pictures would be nice too, but maybe some potential mentors would be put off by that. If possible I would also like to post a link to the mentor's talks at DConf (espcially if the talk is related to the project idea(s)). This should set our idea's list apart from most I have seen so far. Of course I would only post a bio/picture with the potential mentor's consent. 2. I am supposed to have a backup GSOC administrator, in case I pass away unexpectedly or become otherwise incapacitated. Any volunteers ! 3. We also should have backup mentors - if you feel comfortable serving as a backup mentor for one of the posted project ideas then please let me know. 4. I am supposed to summarize our involvement and the successes and challenges of our participation for previous years, and list our pass/fail rate for each year. Can anyone on the forum fill me in on some of this information, especially if you have mentored in the past, or better yet are a past GSOC student still involved with D.
Re: Programming Language for Games, part 3
On 2014-11-04 23:18, deadalnix wrote: Yes, I have yet to implement a check for ctfeability. Cool, perhaps you should not add it :) -- /Jacob Carlborg
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Monday, 3 November 2014 at 22:26:14 UTC, Jack wrote: I'll try and think about this for a while Thanks for the help sir. No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening?
Re: Templates for structures
On Monday, 3 November 2014 at 14:53:29 UTC, Ali Çehreli wrote: It sounds possible but I don't understand it yet. Can you give an example of the input and output to the D code? Ali Thank you Ali. I realized, that my wishes look like serialization. So i decide read and learn code from existent serialization libraries.
Re: Struct template
On Monday, 3 November 2014 at 17:05:21 UTC, John Colvin wrote: static if (is(typeof(T) == int)) should be static if (is(T == int)) T is already a type. I thought this was supposed to produce an error message rather than fail silently... I'm positive this used to be an error. Did it change?
isRangeOf ?
Sometimes I have a function that needs an iterable:
void foo(Range)(Range data)
if (isForwardRange!Range is(Unqual!(ForeachType!Range) ==
int)) {}
So is it a good idea to add a isRangeOf template to Phobos?
void foo(Range)(Range data)
if (isRangeOf!(Range, int)) {}
Bye,
bearophile
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 08:30:34 UTC, Gary Willoughby wrote: On Monday, 3 November 2014 at 22:26:14 UTC, Jack wrote: I'll try and think about this for a while Thanks for the help sir. No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening? Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error.
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On 11/4/2014 7:34 PM, Jack wrote: On Tuesday, 4 November 2014 at 08:30:34 UTC, Gary Willoughby Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. You might start by adding a call to Mix_Init after SDL_Init and before calling any other Mix_* functions. SDL_Init doesn't know anything about the SDL_mixer library. See [1] for details (and don't forget the corresponding Mix_Quit [2]). [1] https://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer_9.html [2] https://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer_10.html#SEC10
Re: Reading unicode string with readf (%s)
https://issues.dlang.org/show_bug.cgi?id=12990 this?
Re: manually call opUnary
On Tuesday, November 04, 2014 07:19:03 Algo via Digitalmars-d-learn wrote:
Is it possible?
As in
{
int a;
a.opUnary!++();
}
no property 'opUnary' for type 'int'
opUnary only exists when it's been declared on a user-defined type. The way
to use it generically is to use the actual operator - ++ in this case. There
might be a case where calling opUnary directly makes sense, but in general,
it really doesn't. Regardless, it doesn't exist for built-ins.
- Jonathan M Davis
Re: isRangeOf ?
On Tuesday, November 04, 2014 09:40:58 bearophile via Digitalmars-d-learn wrote:
Sometimes I have a function that needs an iterable:
void foo(Range)(Range data)
if (isForwardRange!Range is(Unqual!(ForeachType!Range) ==
int)) {}
So is it a good idea to add a isRangeOf template to Phobos?
void foo(Range)(Range data)
if (isRangeOf!(Range, int)) {}
That loses the ability to test which type of range you're talking about. The
normal thing to do is to simply test the range type and the element type
similar to what you're doing in the first case (though normaly,
Unqual!(ElementType!Range) would be used rather than
Unqual!(ForeachType!Range)). And if what you're really trying to do is check
whether the data variable can be used with foreach, and e in
foreach(e; data)
would be an int, calling it a range isn't really correct anyway, since
opApply and container types would also qualify.
- Jonathan M Davis
Re: isRangeOf ?
Jonathan M Davis: That loses the ability to test which type of range you're talking about. Yes, one can think about templates like isForwardRangeOf, etc. But for such specialized cases I think using isForwardRange+is(ElementType) is acceptable and avoids adding too many templates to Phobos. isRangeOf is for the common case where any range is OK (a forward range), and you need a range of items of type T (opApply still gives an iterable but unfortunately it's not compatible with most Phobos. That's why I have not suggested a function named isIterableOf meant to accept opApply too). I have opened an ER: https://issues.dlang.org/show_bug.cgi?id=13682 Bye, bearophile
Re: Pointer across threads
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives tmp. Is this because tmp
and data.data are still pointing to the same address? If this
is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Sorry, it should read
send(proc, tmp, data.len);
Pointer across threads
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives tmp. Is this because tmp
and data.data are still pointing to the same address? If this is
the case, why doesn't the compiler warn me? Or is it something
else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Re: Reading unicode string with readf (%s)
On Monday, 3 November 2014 at 19:37:20 UTC, Ivan Kazmenko wrote:
Hi!
The following code does not correctly handle Unicode strings.
-
import std.stdio;
void main () {
string s;
readf (%s, s);
write (s);
}
-
Example input (Test. in cyrillic):
-
Тест.
-
(hex: D0 A2 D0 B5 D1 81 D1 82 2E 0D 0A)
Example output:
-
ТеÑÑ.
-
(hex: C3 90 C2 A2 C3 90 C2 B5 C3 91 C2 81 C3 91 C2 82 2E 0D 0A)
Here, the input bytes are handled separately: D0 - C3 90, A2
- C2 A2, etc.
On the bright side, reading the file with readln works properly.
Is this an expected shortcoming of %s-reading a string?
No.
Could it be made to work somehow?
Yes. std.stdio.LockingTextReader is to blame:
void main()
{
import std.stdio;
auto ltr = LockingTextReader(std.stdio.stdin);
write(ltr);
}
$ echo Тест | rdmd test.d
ТеÑÑ
LockingTextReader has a dchar front. But it doesn't do any
decoding. The dchar front is really a char front.
Is it worth a bug report?
Yes.
Ivan Kazmenko.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives tmp. Is this because tmp
and data.data are still pointing to the same address? If this
is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:01:16 UTC, anonymous wrote:
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives tmp. Is this because tmp
and data.data are still pointing to the same address? If this
is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Ah, thanks a lot, that was it! It has to be immutable(short)* on
the receiving end, now it works.
receive (
(immutable(short)* data, size_t len) {
//...
});
It is indeed inconveniently literal, but I guess there's a reason
for it.
I'm still curious, though, how D handles this internally, because
data.data is still mutable while the other reference to the same
address (tmp) is not. What if I change data.data while the other
thread is being executed?
PS In this case, it was hard to provide a complete test case,
because there are things going on in a C function and other D
modules.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote:
On Tuesday, 4 November 2014 at 14:01:16 UTC, anonymous wrote:
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives tmp. Is this because
tmp and data.data are still pointing to the same address? If
this is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted
to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Ah, thanks a lot, that was it! It has to be immutable(short)*
on the receiving end, now it works.
receive (
(immutable(short)* data, size_t len) {
//...
});
It is indeed inconveniently literal, but I guess there's a
reason for it.
I'm still curious, though, how D handles this internally,
because data.data is still mutable while the other reference to
the same address (tmp) is not. What if I change data.data while
the other thread is being executed?
Just tested it.
writeln(data.data[0]);
data.data[0] = -11;
send(play, tmp, data.len);
writeln(tmp[0]);
//
receive (
(immutable(short)* data, size_t len) {
writeln(data[0];
});
prints
0 // original value
-11 // tmp
-11 // data in the other thread
Is this behavior intended?
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? Changing *data.data would be undefined behaviour. Don't do it. Once data is typed as immutable, it must not change anymore. By casting you're side-stepping the type system, so that you have to make sure of such things yourself.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:47:49 UTC, anonymous wrote: On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? Changing *data.data would be undefined behaviour. Don't do it. Once data is typed as immutable, it must not change anymore. By casting you're side-stepping the type system, so that you have to make sure of such things yourself. Hm. I'm not planning to change data.data, of course, but I was worried (and curious) about potential safety issues. I suppose I could convert short* to short[] idup it pass a reference to the C function (that expects short*). However, I want to avoid this, because there shouldn't be any additional operations (it's a (near) real time system).
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? immutable is part of the static type system, it's a label that only exists and makes sense at compile time, for compiler and the programmer. Casting a mutable data pointer to immutable data pointer is a no-op, just a copy of pointer. Address stays the same, data stays the same. So if you mutate the data it will lead to immutable data being changed just because it's not really immutable, you've just fooled yourself when doing the cast.
Re: Pointer across threads
On Tuesday, 4 November 2014 at 16:07:11 UTC, thedeemon wrote: On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? immutable is part of the static type system, it's a label that only exists and makes sense at compile time, for compiler and the programmer. Casting a mutable data pointer to immutable data pointer is a no-op, just a copy of pointer. Address stays the same, data stays the same. So if you mutate the data it will lead to immutable data being changed just because it's not really immutable, you've just fooled yourself when doing the cast. That's what I was thinking too.
Re: Pointer across threads
There is assumeUnique which effectively does cast to immutable but is more clear to the reader in a sense why breaking type system was considered legit. I recommend using it over raw cast.
Re: Reading unicode string with readf (%s)
On Monday, 3 November 2014 at 20:03:03 UTC, Ali Çehreli wrote:
On 11/03/2014 11:47 AM, Ivan Kazmenko wrote:
On Monday, 3 November 2014 at 19:37:20 UTC, Ivan Kazmenko
wrote:
readf (%s, s);
Worth noting: this reads to end-of-file (not end-of-line or
whitespace),
and reading the whole file into a string was what I indeed
expected it
to do.
So, if there is an idiomatic way to read the whole file into a
string
which is Unicode-compatible, it would be great to learn that,
too.
I don't know the answer to the Unicode issue with readf but you
can read the file by chunks:
import std.stdio;
import std.array;
import std.exception;
string readAll(File file)
{
char[666] buffer;
char[] contents;
char[] piece;
do {
piece = file.rawRead(buffer);
contents ~= piece;
} while (!piece.empty);
return assumeUnique(contents);
}
void main () {
string s = stdin.readAll();
write (s);
}
Ali
Thank you for suggesting an alternative!
Looks like it would be an efficient one, too.
I believe it can be made a bit more efficient if using an
appender, right?
Still, that's a lot of code for a minute scripting task, albeit
one has to write the readAll function only once.
Re: Reading unicode string with readf (%s)
On Monday, 3 November 2014 at 20:10:02 UTC, Gary Willoughby wrote: On Monday, 3 November 2014 at 19:47:17 UTC, Ivan Kazmenko wrote: So, if there is an idiomatic way to read the whole file into a string which is Unicode-compatible, it would be great to learn that, too. Maybe something like this: import std.stdio; import std.array; import std.conv; string text = stdin .byLine(KeepTerminator.yes) .join() .to!(string); And thanks for a short alternative! At first glance, looks like it sacrifices a bit of efficiency on the way: the remove-line-breaks, then add-line-breaks path looks redundant. Still, it does not store intermediate splitted representation, so the inefficiency is in fact not catastrophic, right?
Re: Reading unicode string with readf (%s)
On Tuesday, 4 November 2014 at 11:46:24 UTC, Kagamin wrote: https://issues.dlang.org/show_bug.cgi?id=12990 this? Similar, but not quite that. Bugs 12990 and 1448 (linked from there) seem to have Windows console as an important part of the process. For me, the example does not work even with files, either redirected via test.exe one.txt two.txt or using File structs inside D program. Still, thank you for the link!
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening? Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. Have you got a copy of the dub.json file you use?
Re: Reading unicode string with readf (%s)
On Tuesday, 4 November 2014 at 13:01:48 UTC, anonymous wrote:
On Monday, 3 November 2014 at 19:37:20 UTC, Ivan Kazmenko wrote:
Hi!
The following code does not correctly handle Unicode strings.
-
import std.stdio;
void main () {
string s;
readf (%s, s);
write (s);
}
-
Example input (Test. in cyrillic):
-
Тест.
-
(hex: D0 A2 D0 B5 D1 81 D1 82 2E 0D 0A)
Example output:
-
ТеÑÑ.
-
(hex: C3 90 C2 A2 C3 90 C2 B5 C3 91 C2 81 C3 91 C2 82 2E 0D 0A)
Here, the input bytes are handled separately: D0 - C3 90, A2
- C2 A2, etc.
On the bright side, reading the file with readln works
properly.
Is this an expected shortcoming of %s-reading a string?
No.
Could it be made to work somehow?
Yes. std.stdio.LockingTextReader is to blame:
void main()
{
import std.stdio;
auto ltr = LockingTextReader(std.stdio.stdin);
write(ltr);
}
$ echo Тест | rdmd test.d
ТеÑÑ
LockingTextReader has a dchar front. But it doesn't do any
decoding. The dchar front is really a char front.
Is it worth a bug report?
Yes.
Ivan Kazmenko.
You nailed it!
Reported the bug in original form:
https://issues.dlang.org/show_bug.cgi?id=13686
Perhaps your reduction would be useful.
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 18:22:49 UTC, Gary Willoughby wrote: On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: No worries. I don't really know what else to suggest without seeing a little code. Do you have a simple full program that shows the error happening? Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. Have you got a copy of the dub.json file you use? Ah, no matter, i've got all the libs installed and linking now.
rndtonl
what am I doing wrong here?
import std.math;
import std.stdio;
void main()
{
real fac;
fac=1.2;
fac=rndtonl(fac);
}
[root@fedorabox util]# dmd bug.d
bug.o: In function `_Dmain':
bug.d:(.text._Dmain+0x3b): undefined reference to `rndtonl'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Re: Reading unicode string with readf (%s)
On Tuesday, 4 November 2014 at 18:09:48 UTC, Ivan Kazmenko wrote: On Monday, 3 November 2014 at 20:10:02 UTC, Gary Willoughby wrote: On Monday, 3 November 2014 at 19:47:17 UTC, Ivan Kazmenko wrote: So, if there is an idiomatic way to read the whole file into a string which is Unicode-compatible, it would be great to learn that, too. Maybe something like this: import std.stdio; import std.array; import std.conv; string text = stdin .byLine(KeepTerminator.yes) .join() .to!(string); And thanks for a short alternative! At first glance, looks like it sacrifices a bit of efficiency on the way: the remove-line-breaks, then add-line-breaks path looks redundant. Still, it does not store intermediate splitted representation, so the inefficiency is in fact not catastrophic, right? And sorry, I didn't read that correctly. Using byLine with KeepTerminator.yes and join with nothing, it does not alter line breaks at all. So, the efficiency of this is entirely up to whether optimizer is able to detect that the break/join sequence is a operation.
Re: rndtonl
I think rndtonl is a C library function that isn't always present in the system. It doesn't work on my computer either and I can't find any documentation about it. It is probably not meant to be called by end users.
Re: [SDL + TKD] Seg fault from creating DirectoryDialog
On Tuesday, 4 November 2014 at 10:34:19 UTC, Jack wrote: Here's the main file: http://codepad.org/hu4r0ExB and Here's the module: http://codepad.org/ikXAzfdg Dependencies are DerelictSDL and Tkd. It's the most simple one I got that reproduces the error. If you change the way SDL is initialised it works. Instead of doing: SDL_Init(SDL_INIT_EVERYTHING); do: SDL_Init(0); SDL_InitSubSystem(SDL_INIT_TIMER); SDL_InitSubSystem(SDL_INIT_AUDIO); SDL_InitSubSystem(SDL_INIT_JOYSTICK); SDL_InitSubSystem(SDL_INIT_HAPTIC); SDL_InitSubSystem(SDL_INIT_GAMECONTROLLER); SDL_InitSubSystem(SDL_INIT_EVENTS); Initialising the following exhibits the crash. // SDL_InitSubSystem(SDL_INIT_VIDEO); So there must be an incompatibility with the video subsystem and tcl/tk.
The interface's 'in' contract passes if it makes a virtual function call
Perhaps I am expecting too much from the current 'in' contract design
and implementation. ;)
Still, the virtual function call in the following interface's 'in'
contract should be dispatched to the implementaion in the derived class,
right?
It seems like mere presence of that virtual function call causes the
'in' contract of the interface succeed and the derived's 'in' contract
never gets called.
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* base's and the derived's in contracts 50% of the time
* because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln(I.foo.in);
/* This check succeeds without calling virtualCheck! */
assert(virtualCheck());
}
bool virtualCheck();
}
class C : I
{
void foo()
in {
writeln(C.foo.in);
}
body
{}
bool virtualCheck()
{
writeln(C.virtualCheck);
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
}
The output has no mention of C.virtualCheck nor C.foo.in:
I.foo.in
-- Where is C.virtualCheck?
-- Where is C.foo.in?
Ali
Re: The interface's 'in' contract passes if it makes a virtual function call
Ali Çehreli: Perhaps I am expecting too much from the current 'in' contract design and implementation. ;) The in contract is named pre-condition, or precondition. Bye, bearophile
Efficient file search and extract
Is there a very easy way to search a file for a string, then extract to a new file everything from that match on to the end of the file? I basically want to remove a header from a file(it's length is not fixed though). It seems I'm having to convert bytes to chars to strings and back and all that mess, which is not very elegant.
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/4/14 3:01 PM, Ali Çehreli wrote:
Perhaps I am expecting too much from the current 'in' contract design
and implementation. ;)
Still, the virtual function call in the following interface's 'in'
contract should be dispatched to the implementaion in the derived class,
right?
It seems like mere presence of that virtual function call causes the
'in' contract of the interface succeed and the derived's 'in' contract
never gets called.
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* base's and the derived's in contracts 50% of the time
* because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln(I.foo.in);
/* This check succeeds without calling virtualCheck! */
assert(virtualCheck());
}
bool virtualCheck();
}
class C : I
{
void foo()
in {
writeln(C.foo.in);
}
body
{}
bool virtualCheck()
{
writeln(C.virtualCheck);
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
}
The output has no mention of C.virtualCheck nor C.foo.in:
I.foo.in
-- Where is C.virtualCheck?
-- Where is C.foo.in?
Ali
This looks like a dmd bug. My theory is that the call to virtualCheck is
going to the WRONG vtbl address. I have seen stuff like this before. It
likely is calling something like toString. You would have to debug to
figure it out.
So what I think happens is it calls the wrong virtual function, which
returns non-zero always, and obviously doesn't print anything, and then
continues on. I added a writeln(after virtual check) to the in
contract of I.foo, and it writes that too.
-Steve
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/4/14 3:26 PM, Steven Schveighoffer wrote:
On 11/4/14 3:01 PM, Ali Çehreli wrote:
Perhaps I am expecting too much from the current 'in' contract design
and implementation. ;)
Still, the virtual function call in the following interface's 'in'
contract should be dispatched to the implementaion in the derived class,
right?
It seems like mere presence of that virtual function call causes the
'in' contract of the interface succeed and the derived's 'in' contract
never gets called.
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* base's and the derived's in contracts 50% of the time
* because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln(I.foo.in);
/* This check succeeds without calling virtualCheck! */
assert(virtualCheck());
}
bool virtualCheck();
}
class C : I
{
void foo()
in {
writeln(C.foo.in);
}
body
{}
bool virtualCheck()
{
writeln(C.virtualCheck);
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
}
The output has no mention of C.virtualCheck nor C.foo.in:
I.foo.in
-- Where is C.virtualCheck?
-- Where is C.foo.in?
Ali
This looks like a dmd bug. My theory is that the call to virtualCheck is
going to the WRONG vtbl address. I have seen stuff like this before. It
likely is calling something like toString. You would have to debug to
figure it out.
So what I think happens is it calls the wrong virtual function, which
returns non-zero always, and obviously doesn't print anything, and then
continues on. I added a writeln(after virtual check) to the in
contract of I.foo, and it writes that too.
Yep. I debugged it. It's calling toHash instead.
Proof (the weird casting thing is because I wanted to call writeln from
toHash, but toHash is nothrow and writeln is not) :
import std.stdio;
void main()
{
/* EXPECTATION: The following call should execute both the
* * base's and the derived's in contracts 50% of the time
* * because the base's contract fails randomly. */
(new C()).foo();
}
interface I
{
void foo()
in {
writeln(I.foo.in);
/* This check succeeds without calling virtualCheck! */
assert(this.virtualCheck());
writeln(after virtual check);
}
bool virtualCheck();
}
void printToHash() { writeln(in toHash);}
class C : I
{
void foo()
in {
writeln(C.foo.in);
}
body
{}
bool virtualCheck()
{
writeln(C.virtualCheck);
/* Fail randomly 50% of the time */
import std.random;
import std.conv;
return uniform(0, 2).to!bool;
}
override size_t toHash() @trusted
{
auto f = cast(void function() nothrow)printToHash;
f();
return 1;
}
}
output:
I.foo.in
in toHash
after virtual check
Please report to bugzilla.
-Steve
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/04/2014 12:41 PM, Steven Schveighoffer wrote:
Yep. I debugged it. It's calling toHash instead.
Yeah, you were spot on. :) I did a different experiment. I added a
number of functions to the interface (before virtualCheck()) and
implementations to the class:
interface I
{
// ...
bool a();
bool b();
bool c();
bool d();
bool virtualCheck();
}
class C : I
{
// ...
bool a() { return false; }
bool b() { return false; }
bool c() { return false; }
bool d() { return false; }
}
Adding only a() calls C's precondition unconditionally (because it
pushes virtualCheck() to the next slot in vtbl.)
Adding a() and b() has the same effect.
Adding a(), b(), and c() prints I.foo.in indefinitely. :)
Finally, adding a(), b(), c(), and d() seems to bring the expected
behavior. :)
Ali
Re: Efficient file search and extract
On Tuesday, November 04, 2014 20:12:21 Sativa via Digitalmars-d-learn wrote: Is there a very easy way to search a file for a string, then extract to a new file everything from that match on to the end of the file? I basically want to remove a header from a file(it's length is not fixed though). It seems I'm having to convert bytes to chars to strings and back and all that mess, which is not very elegant. By far the easiest would be something like import std.algorithm; import std.file; auto fileContents = std.file.readText(filename); auto found = fileContents.find(stringImLookingFor); std.file.write(filename, found); though that requires reading the entire file into memory at once. If you're dealing with a text file, that probably isn't a problem though, and any sane alternatives would require writing to a new file and then moving that file to replace the old one, which is more involved. But std.stdio.File and std.stdio.File.byLine can be used to read the file one line at a time, in which case you'd just not write any of the lines until you found a line with the string that you were looking for, in which case you'd write the part of the line that you wanted to a file, and then write every line after that to the file. Or you could use std.mmfile.MmFile to read the whole file as a memory buffer, use find on that to find the portion that you want and then write it to disk (probably with std.file.write), but that definitely requires some casting and probably only makes sense if you want to be able to use find on the whole file at once without necessarily bringing the entire file into memory at once. Personally, I'd just use std.file.readText and std.file.write though. It's simple, and it would only be a problem if you were dealing with a very large file (which text files normally aren't). - Jonathan M Davis
Re: UDA failling to build when using delegate
On Tuesday, 4 November 2014 at 00:32:52 UTC, bioinfornatics wrote: On Monday, 3 November 2014 at 23:53:53 UTC, bioinfornatics wrote: Dear, why this code fail to build http://dpaste.dzfl.pl/8ef3898b05d2 ? I try to have a structure which is used to fill information from a file. And I use UDA to tell : to get this field you need to read from x to y using a delegate. thanks for your advise with ldc and dmdfe 2.066 i got: $ ldc2 test.d test.d(40): Error: type Section!((letter) = letter == '', (letter) = letter == '\x0a') has no value tuple((Section!((letter) = letter == '', (letter) = letter == '\x0a'))) Section!((letter) = letter == '', (letter) = letter == '\x0a') test.d(92): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(99): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(101): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(109): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(43): Error: type Section!((letter) = letter = 'A' letter = 'z', (letter) = letter == '\x0a') has no value tuple((Section!((letter) = letter = 'A' letter = 'z', (letter) = letter == '\x0a'))) Section!((letter) = letter = 'A' letter = 'z', (letter) = letter == '\x0a') test.d(92): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(99): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(101): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(109): Error: this for countUntil needs to be type Fasta not type Parser!(Fasta, ByChunk) test.d(7): Error: template instance test.Parser!(Fasta, ByChunk) error instantiating No one can to help about uda?
Re: UDA failling to build when using delegate
On 11/04/2014 01:58 PM, bioinfornatics wrote: test.d(40): Error: type Section!((letter) = letter == '', (letter) = letter == '\x0a') has no value You have this line: @Section!(/* ... */) Although that is a type name, there is a bug somewhere and sometimes you have to use a 'value' as a UDA. (We talked about this recently but I don't remember the details.) So make it an object so that it is a 'value': @Section!(/* ... */)() (You have another instance of that.) You will have to deal with the next set of error messages now. :-/ Ali
Re: The interface's 'in' contract passes if it makes a virtual function call
On 11/04/2014 12:26 PM, Steven Schveighoffer wrote: This looks like a dmd bug. Posted: https://issues.dlang.org/show_bug.cgi?id=13687 Ali
[Issue 2255] AA.remove() doesn't remove AA element when iterating using foreach
https://issues.dlang.org/show_bug.cgi?id=2255
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #9 from yebblies yebbl...@gmail.com ---
It's actually fairly easy to check for the most common cases (item removed or
inserted while iterating) by saving the length at the start of iteration, and
checking it hasn't changed before visiting each item. The check needs to be
before visiting, because it's safe to mutate the AA if the loop is exited right
after.
eg
diff --git a/src/rt/aaA.d b/src/rt/aaA.d
index cf4f139..5991393 100644
--- a/src/rt/aaA.d
+++ b/src/rt/aaA.d
@@ -545,10 +545,12 @@ int _aaApply(AA aa, in size_t keysize, dg_t dg)
immutable alignsize = aligntsize(keysize);
//printf(_aaApply(aa = x%llx, keysize = %d, dg = x%llx)\n, aa.impl,
keysi
+auto startLength = aa.impl.nodes;
foreach (e; aa.impl.buckets[aa.impl.firstUsedBucketCache .. $])
{
while (e)
{
+assert(aa.impl.nodes == startLength, AA was modified during
iteration);
auto result = dg(cast(void *)(e + 1) + alignsize);
if (result)
return result;
The big problem is - this check should only be on in debug mode, but nobody
ever uses a debug build of druntime, so it would be useless. I don't even know
how to make debug build of druntime on win32.
--
[Issue 4567] dmd should print the dmd.conf location with usage statement
https://issues.dlang.org/show_bug.cgi?id=4567 --- Comment #9 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e30213d6672bdf7440be662575be2c1cf29b1eb3 Show config file if object.d can't be found. To help troubleshoot problems caused by stray copies of dmd.conf (see bugzilla issue 4567). https://github.com/D-Programming-Language/dmd/commit/96b7b2fdd26fe8b2e4ec8da273d1e2e5c00f6bdc Merge pull request #4108 from quickfur/issue4567 Issue 4567: display dmd.conf path being used if object.d can't be found --
[Issue 3248] lossless floating point formatting
https://issues.dlang.org/show_bug.cgi?id=3248 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #14 from yebblies yebbl...@gmail.com --- (In reply to hsteoh from comment #13) Wouldn't the most lossless format be to just dump the representation in hexadecimal (i.e., in the same format as a hexadecimal float literal)? That way you're guaranteed that you don't get excess precision where there is none, nor do you lose any bits. That would no longer be human-readable. --
[Issue 12648] Array operation return type
https://issues.dlang.org/show_bug.cgi?id=12648 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #3 from yebblies yebbl...@gmail.com --- (In reply to bearophile_hugs from comment #2) I think the good way to solve this bug and others (and to improve D language usability in other ways) is with the enhancement of Issue 13228 I agree. --
[Issue 13524] -cov does not account for inline conditionals
https://issues.dlang.org/show_bug.cgi?id=13524 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com --- (In reply to Andrei Alexandrescu from comment #0) If condition is always the same, one of the function calls isn't covered, and cov does not detect that. Writing the condition on 2-3 lines does work, but coverage analysis shouldn't require code reformatting. It does require reformatting, because dmd's coverage is line-based. I would expect an expression-based coverage implementation to be much more complicated, both in output format and internal implementation. --
