Re: dmd 2.063 beta 5
On Friday, 24 May 2013 at 13:54:21 UTC, Dicebot wrote: There is an option to prohibit initializers for struct member declarations at all and allow CTFE-able default constructors instead, but that would have been a major change. I don't see a reason why we couldn't have both ways (1. member initializers and 2. CTFE-able default constructor) for defining the init state of structs. Probably the sensible thing would be to make all member initializers illegal iff a default constructor has been defined for a struct. I'd be interested in seeing a proper feature request discussion about this in a dedicated forum or at bugzilla.
v1.0.0 of templ-d: An Embedded D Template Engine
Hello everyone,
A few of you might have remembered me posting a proof-of-concept
embedded D template engine a week or two ago. I'd like to
announce that a few weeks of development later, I've extracted
the core idea of that into a Dub-compatible library, called
templ-d.
The syntax that templ-d uses is identical to that of eRuby, so
any Ruby programmers will feel right at home with this. However,
delimiters can easily be changed if you so choose.
Templ-d parses templates at compile time, so there is zero
runtime overhead when rendering templates. An optional object or
struct can be passed into templ-d functions, to provide outside
context to the template.
An example of what the syntax looks like:
% foreach(i; 0..2) {
Index: %= i %
% }
will return the string:
Index: 0
Index: 1
Index: 2
Details about passing in additional contexts and
shorthand/longhand notation plus examples are available at:
https://github.com/dymk/templ-d
The dub package is located at:
http://registry.vibed.org/packages/templ-d
This is the first public-presentable D project I've done, so
critique on the code and pull requests are very welcome. On a
side note, a target I've got for the library is to be an
alternative template engine for vibe-d, a web framework written
in D, but I'll cross that bridge in the future.
Re: dmd 2.063 beta 5
On Monday, 27 May 2013 at 07:32:15 UTC, TommiT wrote: I don't see a reason why we couldn't have both ways (1. member initializers and 2. CTFE-able default constructor) for defining the init state of structs. Probably the sensible thing would be to make all member initializers illegal iff a default constructor has been defined for a struct. I'd be interested in seeing a proper feature request discussion about this in a dedicated forum or at bugzilla. Well, technically we can, of course, it won't be that different from current situation (even more confusing though). Consistency issue Don has convinced me about though is that can't be such thing as member initializer for non-static members, as there is nothing to initialize there. Initialization happens when variable is created and that is defined by combination of T.init, struct literal syntax and constructors. So, contrary to usual local variable use case, the very same member initializer syntax does not really initialize anything, it just changes T.init value. I don't feel it is important enough to actually change anything but worth remembering as language design nitpick.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On 5/24/2013 11:12 PM, Diggory wrote: On 64-bit windows there is also the GetWriteWatch function which lets you access the dirty flag in the page table = no page faults = super efficient concurrent generational GC. Just a shame it doesn't exist on 32-bit systems for some reason. There's all sorts of interesting stuff in 64 bit windows :) The user mode thread scheduler is pretty cool. On the flip side: 32 bit is in its twilight days, and I am reasonably confident the next game I work on will be the last one that even supports 32 bits. Then I can finally use all the new 64 bit goodies :) 32 bits will be reserved for phones and tablets (and even then tablets will probably be making the switch pretty soon-ish)
Re: dmd 2.063 beta 5
Dicebot, el 23 de May a las 16:42 me escribiste:
something I may have actually used in real code writing a low-level
networking library:
struct Packet
{
immutable etherType = 0x0800; // IPv4 by default;
// ...
this(bool IPv6)
{
if (!IPv6)
return; // fine with default, same as Packet.init
else
{
etherType = 0x86DD;
// ...
}
}
}
You can achieve the same with:
if (!IPv6)
etherType = 0x0800;
else
...
There is no need to double-initialize a immutable value. If you want to
make it more explicit, just use something like:
enum defaultEtherType = 0x0800;
if (!IPv6)
etherType = defaultEtherType;
else
...
I don't think that very rare use case, which is perfectly covered by
this workaround justifies the complexity added by this
double-initialization. Also code review becomes a nightmare, when I see
immutable something = 1; I can't assume something will be always 1,
I have to take a look at the whole code looking for constructors. That
SUCKS.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte
Re: dmd 2.063 beta 5
Andrei Alexandrescu, el 23 de May a las 12:57 me escribiste: On 5/23/13 9:12 AM, Don wrote: No, it's not, it's a fix plus a new misfeature. Don, you're wrong. The feature is sensible. The problem with it is that it changes semantics of existing code. Is not sensible for code review. For me the price to pay for a feature that add so little is too high. ROI ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Un paracaidista, que no deja de caer. Lo que me lleva hacia arriba, es lo que me tira hacia abajo.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
Vladimir Panteleev, el 24 de May a las 09:55 me escribiste: When the GC is run: - Use VirtualProtect to mark all mutable memory pages as read-only - Add a vectored exception handler to handle the access violation exception - Resume the GC thread I've tried writing a generational GC for D that used page protection for write barriers a while ago. IIRC, I ran into performance issues (the page faults were rather expensive). Yeah, using memory protection to do what fork does manually is a known approach, discussed even in the Garbage Collection book[1]. The good thing about fork is it's so much easier to implement, and the OS is already highly tuned to do this for you. That's why, even when it might be good to explore, is not a very tempting approach for me (but I have it in mind as an alternative way to fix the potential deadlock caused by glibc internal mutex). This approach does have the benefit that it will not cause pages that have been moved to swap to be pulled out in order to be scanned every time, though. [1] http://books.google.de/books/about/Garbage_Collection.html?id=UdtQMAAJredir_esc=y -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Se ha dicho tanto que las apariencias engañan Por supuesto que engañarán a quien sea tan vulgar como para creerlo
Re: dmd 2.063 beta 5
On Monday, 27 May 2013 at 17:08:19 UTC, Leandro Lucarella wrote: You can achieve the same with: if (!IPv6) etherType = 0x0800; else ... There is no need to double-initialize a immutable value. As I have already answered to Don it is all about T.init - only way to change it currently is to use initalizer syntax. It is hardly an issue with this use case - more like the general issue that such syntax was chosen for something that does not mean initialization.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote: On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote: I'd like to know if there is interest in a precise garbage collector. There is interest in it, and Rainer Schütze did a talk on it at DConf. At the current pace (assuming that Andrei actually posts one on Monday even though it's a federal holiday in the US), it'll be posted on June 3rd (and if he skips Monday, then it'll probably be June 5th). And actually, the precise GC changes stand a much better chance of making it into druntime in the short term than any concurrency changes do. - Jonathan M Davis That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a deal breaker for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon. -- Brian
Re: dmd 2.063 beta 5
Steven Schveighoffer, el 23 de May a las 23:53 me escribiste: On Thu, 23 May 2013 23:38:32 -0400, Walter Bright newshou...@digitalmars.com wrote: On 5/23/2013 7:38 PM, Steven Schveighoffer wrote: This is one change where ALL code broken by this change is fixable with a simple solution, and at some point, people will have to deal with this. Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning. If they aren't in the mood to change their code, they don't have to upgrade to the latest compiler. That's completely FALSE. You might need some bugfixes! That view of if you want to be up to date you have to be willing to update a lot of code is really hurting D's stability. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab
New std.uni Approved
With a vote 15/0 the new standard std.uni is approved to replace the existing module. Several people were in favor of the name changing to std.unicode others opposed unless it was part of a Phobos restructure. Such is up to the core devs to decide. Congrads Dmitry.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 27 May 2013 at 17:56:10 UTC, Brian Rogoff wrote: On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote: On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote: I'd like to know if there is interest in a precise garbage collector. There is interest in it, and Rainer Schütze did a talk on it at DConf. At the current pace (assuming that Andrei actually posts one on Monday even though it's a federal holiday in the US), it'll be posted on June 3rd (and if he skips Monday, then it'll probably be June 5th). And actually, the precise GC changes stand a much better chance of making it into druntime in the short term than any concurrency changes do. - Jonathan M Davis That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a deal breaker for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon. -- Brian It's actually possible to improve the precision of the GC without any additional type info. As long as you can give some unique ID to each type when you allocate it then the GC can learn the layout of that type on the fly. For example a simple algorithm would be: - When a new ID is first see create new type-info that is all pointers. - While scanning an instance of that type, if a pointer points to a value in the higher half, or a sufficiently low value which is not equal to zero, then remove this pointer from the type-info. You would have to disable this for unions, but for the rest it should work fine. Plus with more intelligent algorithms you can handle more cases. You could even save the type-info to a file and reuse it later to improve performance.
