Re: Why is null lowercase?
On Friday, 25 January 2013 at 01:17:44 UTC, Ali Çehreli wrote: On 01/24/2013 12:42 PM, Matthew Caron wrote: for not null checks if ( ptr !is null) ... And too much perl has me wanting to write: if (ptr is not null) IIRC, the !is operator is thanks to bearophile. No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007.
Re: Why is null lowercase?
On 01/25/2013 06:22 AM, Don wrote: IIRC, the !is operator is thanks to bearophile. No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007. Ok. How about !in then? Did he lobby for that one? :) Ali
Re: Segfault in _d_dynamic_cast ()
I found what the root of all evil was - The GC. After disabling it, the program runs fine.
Re: Why is null lowercase?
On Friday, 25 January 2013 at 14:22:20 UTC, Don wrote: On Friday, 25 January 2013 at 01:17:44 UTC, Ali Çehreli wrote: On 01/24/2013 12:42 PM, Matthew Caron wrote: for not null checks if ( ptr !is null) ... And too much perl has me wanting to write: if (ptr is not null) IIRC, the !is operator is thanks to bearophile. No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007. It would be nice a to have a wiki page about D history written by old-timers.
Re: Segfault in _d_dynamic_cast ()
On Friday, 25 January 2013 at 15:15:32 UTC, Minas Mina wrote: I found what the root of all evil was - The GC. After disabling it, the program runs fine. Perhaps you was working with C code, GC + legacy code sometimes lead to logical memory errors. However GC per se is unlikely to cause any errors (I remember Walter was telling that neither he nor anybody faced issues with GC). Also your code may still have errors but absence of GC hides them.
Re: Coping files and folders
On 01/24/2013 10:23 PM, Joel wrote:
// parallel foreach for regular files
foreach(fn ; taskPool.parallel(files,100)) {
What is the 100 number for?
It is the work unit size:
http://dlang.org/phobos/std_parallelism.html#.TaskPool
Quoting:
The number of elements processed per work unit is controlled by the
workUnitSize parameter. Smaller work units provide better load
balancing, but larger work units avoid the overhead of communicating
with other threads frequently to fetch the next work unit. Large work
units also avoid false sharing in cases where the range is being
modified. The less time a single iteration of the loop takes, the larger
workUnitSize should be. For very expensive loop bodies, workUnitSize
should be 1. An overload that chooses a default work unit size is also
available.
Ali
Re: Why is null lowercase?
On Friday, 25 January 2013 at 14:43:01 UTC, Ali Çehreli wrote: On 01/25/2013 06:22 AM, Don wrote: No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007. Ok. How about !in then? Did he lobby for that one? :) //hmmm doesn't read right if (ptr in not null) //huh? is it an array or an AA now? if (ptr not in null) //ummm feels like an AA. I'm sure if we used //it it would become second nature. if (ptr !in null) //silently converts to...? if (!(ptr in null)) //make sense to me. Course in java === was //used for ptr checking rather than contents. if (ptr === null) //is null if (ptr !== null) //not null, both stand out //mentally I reverse !is to equal 'is not'. //I know I'm comparing pointers. if (ptr !is null) Code example: string[string] aa; string* ptr; if (dog in aa)//returns ptr if (dog !in aa)//i think it's bool of 'found' ptr = dog in aa; if (ptr in null) //errors, not an aa, searching null? if (ptr!in null) //not searching null? change to... string[string[string]] aa; string[string]* ptr; //(string[string])* ptr; ?? if (dog in aa) //returns ptr (of an aa), search if (dog !in aa) //still makes sense... a search. ptr = dog in aa; if (ptr in null) //becomes ((*ptr) in aa), search? //(!((*ptr) in null))//AA search or pointer compare? if (ptr!in null) null can still be replaced by any variable/pointer, if that pointer is an aa as well... Ugg I don't wanna find out all the combinations to figure it out... After looking at all these 'in' should be reserved for array searching, not pointer checking. It makes more sense to me that way.
Re: Why is null lowercase?
On 01/25/2013 10:31 AM, Era Scarecrow wrote: On Friday, 25 January 2013 at 14:43:01 UTC, Ali Çehreli wrote: On 01/25/2013 06:22 AM, Don wrote: No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007. Ok. How about !in then? Did he lobby for that one? :) //ummm feels like an AA. I'm sure if we used //it it would become second nature. if (ptr !in null) Isn't that an error to apply the in operator to null? The expression above is syntactic sugar for the following one: !null.opBinaryRight!in(ptr)) Yes, there is also opBinary!in but it doesn't make sense to me to put the container on the left-hand side ever: if (myContainer in myElement) Doesn't make sense. After looking at all these 'in' should be reserved for array searching, not pointer checking. It makes more sense to me that way. Sorry if I implied otherwise. Yes, 'in' should be for that purpose. I merely tried to remember what syntax has been bearophile's strong suggestion. ;) Ali
Re: Why is null lowercase?
On Friday, 25 January 2013 at 18:57:06 UTC, Ali Çehreli wrote: On 01/25/2013 10:31 AM, Era Scarecrow wrote: After looking at all these 'in' should be reserved for array searching, not pointer checking. It makes more sense to me that way. Sorry if I implied otherwise. Yes, 'in' should be for that purpose. I merely tried to remember what syntax has been bearophile's strong suggestion. ;) Not so much implied as considered. Had it been used, it would be obvious there was problems with it, both with meanings and added ambiguities. Oh well. One thing at a time..
Re: Segfault in _d_dynamic_cast ()
Maybe. I am re-writing the code in C++ to see, and also to compare the performance.
Re: Segfault in _d_dynamic_cast ()
On Friday, 25 January 2013 at 16:19:15 UTC, Maxim Fomin wrote: On Friday, 25 January 2013 at 15:15:32 UTC, Minas Mina wrote: I found what the root of all evil was - The GC. After disabling it, the program runs fine. Perhaps you was working with C code, GC + legacy code sometimes lead to logical memory errors. However GC per se is unlikely to cause any errors (I remember Walter was telling that neither he nor anybody faced issues with GC). Also your code may still have errors but absence of GC hides them. I have written the same program in C++ -- and I get no seg-fault. Well I don't know for sure that something isn't wrong with my code, but I suspect it is the GC that is messing things up.
Re: Segfault in _d_dynamic_cast ()
I have written the same program in C++ -- and I get no seg-fault. Well I don't know for sure that something isn't wrong with my code, but I suspect it is the GC that is messing things up. This is definitly possible, I also had random segfaults GC related. It worked fine on my PC, but crashed on someone elses Ubuntu (same DMD version, same architecture). I also had random crashes in threads when they were about to finish, GC.disable() solved it, also rewriting the whole code (fortunatly I had to do that anyways)
Re: Coping files and folders
I also wrote a copy version that orders file sequence on disk efficiently, using write through, and posted it. This speeds up any subsequent file system operations done in the directory order as if you have done a defrag. Great for hard drives, but not needed for ssd. https://github.com/jnorwood Any change you could turn this into a pull request and submit to Phobos? Looks like I never promoted the write through code on github. I just posted it on the forum.dlang.org, along with some timings. I was only experimenting on ntfs, and so the extension I posted doesn't force write-through on linux. http://forum.dlang.org/thread/gmkocaqzmlmfbuozh...@forum.dlang.org After re-reading my post, I don't think I experimented with write through in copydir. I show the timings in the post for ntfs operations on a 2GB layout after unzipping with a write through version of unzip. I suspect you'd see similar improvement following a copydir that uses write through. The problem I saw with ntfs was that the target directory was very fragmented when allowing ntfs to do its lazy flushes. I tried several experiments, and using the write through was the only solution that resulted in a reasonably defragged target immediately as the result of the unzip.
