Re: Template bug with second mixin?
On Fri, 05 Dec 2014 07:06:34 +
Andre via Digitalmars-d-learn wrote:
> Hi,
>
> following coding fails to compile with 2.066.0 and
> 2.067.0-b1.
>
>
> This is a bug, or?
> source\app.d(9): Error: mixin
> app.Data.insertReadMethods!("readTinyInt", ubyte)
> is not defined
>
> template insertReadMethods(string MethodName, DataType)
> {
> enum insertReadMethods = "";
> }
>
> struct Data
> {
> mixin insertReadMethods!("readTinyInt", ubyte);
> mixin insertReadMethods!("readTinyInt", ubyte);
> }
>
> void main(){}
i.e. "mixin template" inserts it's names into the same scope, and
compiler searching symbols from innermost scope up to module scope.
here first mixin inserts 'enum' member, and searching for second mixin
hits that enum member. to avoid things going out of control compiler is
not trying to guess what you want but stops with error, giving you a
chance to fix the code.
signature.asc
Description: PGP signature
Re: Template bug with second mixin?
On Fri, 05 Dec 2014 07:06:34 +
Andre via Digitalmars-d-learn wrote:
> Hi,
>
> following coding fails to compile with 2.066.0 and
> 2.067.0-b1.
>
>
> This is a bug, or?
> source\app.d(9): Error: mixin
> app.Data.insertReadMethods!("readTinyInt", ubyte)
> is not defined
>
> template insertReadMethods(string MethodName, DataType)
> {
> enum insertReadMethods = "";
> }
>
> struct Data
> {
> mixin insertReadMethods!("readTinyInt", ubyte);
> mixin insertReadMethods!("readTinyInt", ubyte);
> }
>
> void main(){}
not a bug. what you doing is actually:
struct Data
{
enum insertReadMethods = "";
mixin insertReadMethods!("readTinyInt", ubyte);
}
`enum insertReadMethods` is definitely not a template, and compiler
correctly tells that to you.
signature.asc
Description: PGP signature
Template bug with second mixin?
Hi,
following coding fails to compile with 2.066.0 and
2.067.0-b1.
This is a bug, or?
source\app.d(9): Error: mixin
app.Data.insertReadMethods!("readTinyInt", ubyte)
is not defined
template insertReadMethods(string MethodName, DataType)
{
enum insertReadMethods = "";
}
struct Data
{
mixin insertReadMethods!("readTinyInt", ubyte);
mixin insertReadMethods!("readTinyInt", ubyte);
}
void main(){}
Kind regards
André
Re: threading issues with D -> C -> Python
On 12/04/2014 02:11 PM, Michael wrote: On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer wrote: dustmite? Not sure what went wrong with dustmite, but every time I tried it it just started deleting all the files in the directory and setup.py would give errors. I manually deleted a reasonable chunk of the code and I'm left with these files which still seem to cause segfaults: Main code: http://pastebin.com/zqgNTk9w PyD definitions: http://pastebin.com/6mRH3KZZ setup.py: http://pastebin.com/i9Ph78UC test code that causes segfaults: http://pastebin.com/1ukzShVh Cheers, Michael. hmm.. looks like here it originates in python when it tries to acquire the GIL. specifically, pthread_cond_timedwait is segfaulting. in your code, execution inside a python thread makes it to receiveTimeout in get_image. it made it past receiveTimeout in acquire. then I guess there is a context switch. the main python thread throws an exception, but a number of things trigger the segfault. I think it's just the interpreter loop calling RestoreThread. backtrace looks like #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 0x003799d07bb3 in PyCOND_TIMEDWAIT (cond=0x379a063220 , mut=0x379a0631e0 , us=5000) at /usr/src/debug/Python-3.3.2/Python/condvar.h:103 #2 take_gil (tstate=tstate@entry=0x604410) at /usr/src/debug/Python-3.3.2/Python/ceval_gil.h:224 #3 0x003799d081fb in PyEval_RestoreThread (tstate=tstate@entry=0x604410) ... It looks like this is the python main thread. I see two other threads. (i took out one of your python spawns) #2 looks to be your listener thread. std.concurrency.send seems to have gotten it into a gc_malloc, but it looks like it's just waiting. it's currently in sem_wait. this one would have been spawned in D code by #3 #3 is your other python thread. it is also in pthread_cond_timedwait. by its stack trace, receiveTimeout is just waiting. I guess tomorrow I can try messing around with thread_attachThis, as the fullcollect happening in #2 might be screwing with python data. But you aren't really passing anything from python to d or vice versa, so I'm not sure why the gc would need to know about the python threads. not exactly my area of expertise, this.
Re: threading issues with D -> C -> Python
On Thu, Dec 04, 2014 at 10:11:53PM +, Michael via Digitalmars-d-learn wrote: > On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer wrote: > > > >dustmite? > > Not sure what went wrong with dustmite, but every time I tried it it > just started deleting all the files in the directory and setup.py > would give errors. [...] Nothing is wrong with dustmite; one of its standard techniques to reduce code is to delete source files and see if the problem still happens (i.e., it's independent of that file). What you need to do is to craft a test script such that only the specific error you're looking for will return a success status, and everything else won't. Then when dustmite deletes an essential file, it will know that that was a wrong step and backtrack. T -- Food and laptops don't mix.
Re: threading issues with D -> C -> Python
On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer wrote: dustmite? Not sure what went wrong with dustmite, but every time I tried it it just started deleting all the files in the directory and setup.py would give errors. I manually deleted a reasonable chunk of the code and I'm left with these files which still seem to cause segfaults: Main code: http://pastebin.com/zqgNTk9w PyD definitions: http://pastebin.com/6mRH3KZZ setup.py: http://pastebin.com/i9Ph78UC test code that causes segfaults: http://pastebin.com/1ukzShVh Cheers, Michael.
Re: Is this a bug or am I doing something wrong?
On 12/04/2014 06:37 AM, Steven Schveighoffer wrote: All that being said, what a horrible error message! https://issues.dlang.org/show_bug.cgi?id=13818 Ali
Re: Is this a bug or am I doing something wrong?
On 12/3/14 6:09 PM, Ali Çehreli wrote: On 12/03/2014 03:02 PM, drsneed wrote: Check out http://dpaste.dzfl.pl/a5ada78fccf5 If my function named "IWillNotCompile" is run, I get an error stating "Component!int' and 'Component!int' are not compatible." If my function named "IWillCompile" is run, there are no errors. They do the same thing, just written slightly differently. Any suggestions? Unlike C++, rvalues cannot be bound to reference parameters even if reference to const. Make the parameter 'auto ref' and it will compile: Component!(T) opBinary(string op)(auto ref Component!(T) rhs) For auto ref, the function must be a template so that the compiler can generate by-reference and by-value versions of it depending on whether the argument is lvalue versus rvalue. Here is my understanding of the issue: http://ddili.org/ders/d.en/lvalue_rvalue.html All that being said, what a horrible error message! -Steve
Re: release building problem
renaming struct from 'Client' to 'MClient' resolve question
Re: @property usage
On Thu, 04 Dec 2014 10:21:10 + uri via Digitalmars-d-learn wrote: > Do you guys use @property much, or is it largely ignored/avoided? i'm using it alot for the things that looks like properties. ;-) the thing is looking like a property if it works almost as fast as accesing the field directly. i.e. does simple check or two, but doesn't calculate something heavy. that means that `area` for Rect is definitely a property, but `equalElementCount` for a single-linked list is not. i also using that alot to simulate read-only fields. signature.asc Description: PGP signature
Re: template bug?
On Wednesday, 3 December 2014 at 18:25:41 UTC, bearophile wrote:
Ali Çehreli:
Attempting to compile with a recent dmd git head causes
segmentation fault. Any compiler crash is a compiler bug.
Please report it at
https://issues.dlang.org/
Ali
A first reduction for Bugzilla:
alias TypeTuple(T...) = T;
struct A {
void foo() {}
}
template ItemProperty(item, string method) {
static if(__traits(getProtection, ItemProperty!(item,
method)).stringof)
alias ItemProperty = TypeTuple!(ItemProperty!(item,
method));
}
void main() {
auto l = ItemProperty!(A, "foo").length;
}
Bye,
bearophile
Thanks for the code revised version. I thought that the compiler
crashes because I was trying to get the access of an overrided
method.
Bogdan
Re: @property usage
On Thursday, 4 December 2014 at 10:24:00 UTC, Rikki Cattermole wrote: On 4/12/2014 11:21 p.m., uri wrote: Hi All, Do you guys use @property much, or is it largely ignored/avoided? Thanks, uri When it makes sense I use it. https://github.com/Devisualization/window/blob/master/interfaces/devisualization/window/interfaces/window.d#L144 vs https://github.com/rikkimax/Dobol/blob/master/source/dobol/parser/dobol/parser/defs.d Thanks for the examples. As always I found what I needed just after posting: http://wiki.dlang.org/Property_Discussion_Wrap-up /uri
Re: @property usage
On 4/12/2014 11:21 p.m., uri wrote: Hi All, Do you guys use @property much, or is it largely ignored/avoided? Thanks, uri When it makes sense I use it. https://github.com/Devisualization/window/blob/master/interfaces/devisualization/window/interfaces/window.d#L144 vs https://github.com/rikkimax/Dobol/blob/master/source/dobol/parser/dobol/parser/defs.d
Re: How to ensure a thread cannot be blocked by the GC?
On Thursday, 4 December 2014 at 08:18:23 UTC, ponce wrote: In fact I was registering them both with core.sys.windows.dll.dll_thread_attach() when callbacked with DLL_THREAD_ATTACH, but I see now that I should instead register to the runtime only the interruptible thread. Yes, I assume you should still call it for the real time thread, but with the first param set to false? bool dll_thread_attach( bool attach_thread = true, bool initTls = true ) Made-up problem! Made-up problems can be very useful. I got some new ideas for real time GC support when thinking about this… ;-)
@property usage
Hi All, Do you guys use @property much, or is it largely ignored/avoided? Thanks, uri
Re: How to ensure a thread cannot be blocked by the GC?
On Thursday, 4 December 2014 at 02:01:26 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 December 2014 at 01:36:13 UTC, Ola Fosheim Grøstad wrote: So I suppose none of your threads are suspended unless you suspend it with Thread on call_back entry? But why suspend a @nogc thread? What a mess of incorrect recollection and typos (it is late, 3AM :-P): I meant to say that I suppose none of your threads are suspended unless you register it as a Thread Thanks Ola & Jacob. In fact I was registering them both with core.sys.windows.dll.dll_thread_attach() when callbacked with DLL_THREAD_ATTACH, but I see now that I should instead register to the runtime only the interruptible thread. Made-up problem!
Re: More flexible sorted ranges?
On Sunday, 2 November 2014 at 15:13:37 UTC, bearophile wrote:
I have often arrays that are sorted, and sometimes I'd like to
append items to them. So I'd like to write something like:
SortedRange!(Foo[], q{ a.x < b.x }) data;
data ~= Foo(5);
immutable n = data.upperBound(Foo(2)).length;
This means having an array of Foos as sorted range, and
appending an item to it keeping the sorting invariant (so in
non-release mode the append verifies the array is empty or the
last two items satisfy the sorting invariant), and this allows
me to call functions like upperBound any time I want on 'data'
without using any unsafe and unclean assumeSorted.
Is this possible and a good idea to do?
Bye,
bearophile
To make it compatible with std.container, you should call it
Sorted(T, pred) and make it a accept any std.container, whose
opSlice returns a RandomAccesRange. A Sorted(Array!U, pred)
wouldn't itself be a RandomAcessRange but a container and it's
opSlice should return a SortedRange.
The algorithms that work on arrays and currently return a
SortedRange could retur n a Sorted!(U[], pred) instead.
Re: How to ensure a thread cannot be blocked by the GC?
On 2014-12-03 23:53, ponce wrote: I have a DLL written in D that gets called by two different threads, created by a non-D host program (audio plugin). I did not create those threads, but my understanding is that they get "attached" to the D runtime. No, the runtime in D doesn't know anything about threads created outside of D, unless you explicitly register them with the runtime. -- /Jacob Carlborg
Re: Sorted Array Wrapper Range
On Wednesday, 3 December 2014 at 21:02:05 UTC, Nordlöw wrote: Have anybody written a generic automatically sorted range wrapper for RandomAccessRanges? I guess http://dlang.org/library/std/range/assumeSorted.html should play a key role. I see two typical variants: - Direct: Always sorts on write() and modify() - Lazy: Sorts lazily on read() read() of course uses binarySearch You won't be able to grow that range, would you?
