Re: Do not use 2.041
Steven Schveighoffer wrote: If a good debugger existed for dmd, you could determine the location, but I don't know of any good ones. gdb doesn't do a very good job with D. dmd has produced debugging information that makes gdb choke up for ages. This makes gdb (and some other utilities that try to read debugging infos) useless for D. Is this gdb's or dmd's fault?
Re: dmd 1.057 and 2.041 release
Robert Jacques wrote: On Mon, 08 Mar 2010 16:42:54 -0500, Philippe Sigaud philippe.sig...@gmail.com wrote: On Mon, Mar 8, 2010 at 14:22, Steven Schveighoffer schvei...@yahoo.comwrote: The shrinkToFit name is not my favorite, anyone care to submit a better name? minimize is out because it has connotations of math already. minCapacity minimizeCapacity shrinkCapacity shrink (just shrink) releaseCapacity compacify fitCapacity minFit??? reduceToFit contract minify adjust Philippe compact Many of these names (including shrinkToFit) suggest that memory usage is reduced by freeing the left over memory after the array. This is not true: the function just enables stomping of the memory past the slice passed to the function. It's a very specialized and dangerous function (but still may be critical for good performance), and maybe it should rather have a more convoluted/long name than a simple one.
Re: obj2asm
Walter Bright wrote: Trass3r wrote: obj2asm tells the tale. (obj2asm is an incredibly useful tool, I don't know why nobody uses it.) Maybe because it's not free (and not much advertised). obconv also supports disassembling various object file formats + conversion between them and it's open source: http://www.agner.org/optimize/#objconv obj2asm might provide something fancy that objconv doesn't but its page doesn't show anything that would justify paying 10$. At first glance, obj2asm will pretty-print the codeview debug info in the object file, and will mix source lines with corresponding assembler lines. Obj2asm also comes with a bunch of other utilities, any one of which is worth the $15 if you need them: ◦chmod Change/list file attributes ◦coff2omf Convert COFF object and lib files to OMF ◦diff Compare text files ◦diffdir Compare directory trees ◦dump Dump files ◦dumpexe Dump executable files ◦dumpobj Dump object files ◦flpyimg Read/Write floppy disk image ◦grep Search files for strings ◦libunres Scan libraries for unresolved externals ◦makedep Makefile dependency generator ◦obj2asm Object file disassembler ◦patchobj Patch object files ◦smake Advanced make program ◦whereis Search for files http://www.digitalmars.com/ctg/obj2asm.html Why not give them out to free? Especially coff2omf seems to be critical, if you want D to be a success.
Re: obj2asm
Trass3r wrote: The linux version comes in the zip right along side dmd. Indeed. Even the OSX folder contains obj2asm. The windows version is missing. The best thing is, on Linux you can use binutils objdump just fine. I'm sure OSX has tools to inspect object files as well. Only on Windows, you're having a bad time: almost nothing can understand digitalmars-omf.
Re: dmd 1.056 and 2.040 release
BLS wrote: On 30/01/2010 08:13, Walter Bright wrote: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.056.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.040.zip Thanks to the many people who contributed to this update! Instead of complaining (as usual) I would like to say Thank You for opening the complete D source code. Don't forget thanking Walter for using a public version controlled repository. It is pretty clear that since D is open sourced we got much more fixes, and, not to forget, another level of ideas regarding future development tasks. well done. Bjoern
Re: dmd beta mailing list
Walter Bright wrote: Walter Bright wrote: grauzone wrote: Why are you creating these as mailing lists and not as news.digitalmars.com groups? Because I expect it to be very low traffic, and I wouldn't expect people to constantly have to check the n.g. to see if the beta is available. It also gives feedback on who actually cares about the beta. There's also the fact that there's a very small barrier to subscribing to a mailing list - only people who are particularly interested in it will bother. I've seen the mailing list approach used elsewhere because of this, and it works well. Why would you put up a barrier for beta-testing? The concurrency mailing list I can understand (that's Andrei's thing).
Re: dmd 1.054 and 2.038 release
Walter Bright wrote: Happy New Year! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.054.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.038.zip Many thanks to the numerous people who contributed to this update. Tons of bug fixes == great! But I have a problem: the compiler is either extremely slow for me, or is stuck in an endless loop. All it does is to slowly allocate memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile. Can anyone confirm this?
Re: dmd 1.054 and 2.038 release
bearophile wrote: grauzone: But I have a problem: the compiler is either extremely slow for me, or is stuck in an endless loop. All it does is to slowly allocate memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile. Can anyone confirm this? Show the code! I was going to say but it's hundreds of modules, but then I tried to compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/Demangler.d?rev=5248 The exact command line for this was: dmd -c -I../tango/core -I.. -I../tango/core/vendor -release -oftango-core-tools-Demangler-release.o ../tango/core/tools/Demangler.d Again, could anyone confirm this? Anyway, no time for this anymore, it's going to be 2010 soon here. Bye, bearophile
Re: Code Poet, an IDE for D
retard wrote: Wed, 11 Nov 2009 10:00:58 +0100, grauzone wrote: Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Oh dear, that's not good publicity for D... I know the implementation language doesn't really matter, but it's just not good publicity. Well, you sometimes have to accept that if the language isn't really production quality yet, it's counterproductive to use it for real world projects. When developing the IDE with C++, he will probably not run into that many compiler bugs. With D each 500..1000 lines of code would probably expose at least one bug. I understand, but others not knowing D won't. That's the problem. (PS: I don't think there are that many compiler bugs anymore; the larger problem are indeed the GUI bindings, especially the memory managment aspect.)
Re: Metaprogramming in D : Some Real-world Examples
Andrei Alexandrescu wrote:
grauzone wrote:
Lars T. Kyllingstad wrote:
Jacob Carlborg wrote:
On 11/10/09 01:27, Bill Baxter wrote:
On Mon, Nov 9, 2009 at 4:09 PM, Walter Bright
newshou...@digitalmars.com wrote:
Looks like Bill Baxter is giving a presentation on D Nov. 18!
http://www.nwcpp.org/
Yep, that's right, and I'd be quite grateful to you smart folks here
if you could share your meta-programming favorites with me! If
you've got a real-world example of meta-programming in D that you
think is particularly handy, then please send it my way
I'm looking for small-but-useful things that are easy to explain, and
make something easier than it would be otherwise. Things like places
where static if can save your butt, or loop unrolling, and passing
code snippets to functions like in std.algorithm.
Things like a compile-time raytracer or regexp parser (though quite
cool!) are not what I'm after. Too involved for a short talk.
--bb
This is invaluable to me, which makes it possible to do some form of
duck typing at compile time:
static if (is(typeof({
/* does this compile */
})))
There are forces at work (Don, that is) attempting to get rid of that
very construct and replace it with something better:
http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html
In my humble opinion, is(typeof({...})) is an ugly creature. I really
don't think it should be put under a spotlight as a good example of D
metaprogramming. If anything, please use __traits(compiles, {...})
instead.
Who cares about ugly syntax, if the idea is bad in the first place?
I think testing types during compilation isn't bad. Under what
circumstances is it?
You're not testing for types, you're testing if it compiles. Inside the
tested block of code, all sorts of things could go wrong. You can't know
if is(typeof(...)) really did what you wanted, or if something broke. At
least when you're doing more complex stuff with is(typeof), the danger
of silent failures increases. Suppose the user makes an error in his
custom range type by specifying a wrong return type (or whatever), and
the range library just ignores his range-related function. Maybe that
range function was optional, which will end in the range library
seemingly ignoring his function. Can this be good? (I don't know if that
case I described can even happen in your ranges lib, but I think this is
a typical failure that could happen with is(typeof).)
This isn't even compiletime duck typing anymore, it's try-and-error
built into the compiler. Even worse, now having semantically incorrect
code in D sources is perfectly fine for weird reasons, and the compiler
has to swallow some kinds of semantics errors.
Really, wouldn't some mechanism to explicitly check for compile time
contracts better?
For me, this is some sort of metaprogramming WTF. This all makes me
cringe. Sorry about that.
Andrei
Re: Metaprogramming in D : Some Real-world Examples
Andrei Alexandrescu wrote:
grauzone wrote:
Don wrote:
Christopher Wright wrote:
grauzone wrote:
You're not testing for types, you're testing if it compiles. Inside
the tested block of code, all sorts of things could go wrong. You
can't know if is(typeof(...)) really did what you wanted, or if
something broke.
You're testing, is everything inside that OK?. If you want to know
WHY it's wrong, you'd better make sure you're testing something simple.
Andrei's range lib uses it more in a way does this type support this
and that range interface?. Example:
http://dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L58
Then different isXxxRange are used by higher-order ranges in defining
refined interfaces depending on the interfaces offered by their inputs.
That means if one isXxxRange fails because the user maybe made a typo in
the needed range function, the code will silently do something else.
But my main problem is that the user just gets a does not match
template declaration compiler error when he messes up his range
interface. He's neither told that e.g. his range-related function
returns the wrong type, nor is there any other refined error message.
Now what if we'd introduce some sort of interfaces for type checking at
compile time?
interface InputRange(T) {
void popFront();
bool empty();
T front();
}
struct MyRange : InputRange!(int) {
void popFront() { ... }
//compiler error goes here...
void empty() { ... }
int front() { ... }
}
(or something like this)
PS: there are two aspects to the problem: 1. even compile time duck
typing shares some of the problems of runtime duck typing, and 2.
utterly unhelpful error messages. If you wouldn't explicitly check the
interface with is(typeof()), the compiler's error messages would be even
worse because of 1.
I fail to see how that's terrible. I am very happy D has that feature -
no other statically-typed language has it, and it can be used to great
effect. Look e.g. at Chain:
http://dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L799
There, the uses of static if (is(...)) allow Chain to define as capable
an interface as its inputs allow.
Andrei
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
Walter Bright wrote: Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you). Additionally, I prefer a slow, working linker over a fast, crashing one.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
Leandro Lucarella wrote: grauzone, el 4 de noviembre a las 17:23 me escribiste: Walter Bright wrote: Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow. And if you really find it slow, GNU Gold (done by Google) is *much* faster. Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?
Re: dmd 1.048 and 2.033 releases
Jarrett Billingsley wrote: On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger. As I understand, -0 just enables flow analysis (which is slow and thus shouldn't be run normally), not full optimization.
Re: dmd 1.048 and 2.033 releases
Denis Koroskin wrote: On Wed, 07 Oct 2009 00:54:22 +0400, grauzone n...@example.net wrote: Jarrett Billingsley wrote: On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger. As I understand, -0 just enables flow analysis (which is slow and thus shouldn't be run normally), not full optimization. No, -O means optimize. It's just much easier to check code flow when an executable is optimized, that's it. And I thought it was a zero... never mind, then.
Re: Crash handler with stack trace
Jeremie Pelletier wrote: I've been asked for my runtime crash handler with it's CodeView reader earlier in digitalmars.D so here it is: http://jump.fm/UVYHG Wanted to take a look at it again, but the site is defunct.
Re: spiritd
I use ff. looks ok to me. Maybe your just using a tiny resolution? (does anybody use less than 1680x1050 these days?) I don't think you should design your website in such a way, that only users with specific hardware can view it.
Re: dmd 1.046 and 2.031 releases
Walter Bright wrote: のしいか (noshiika) wrote: Thank you for the great work, Walter and all the other contributors. But I am a bit disappointed with the CaseRangeStatement syntax. Why is it case 0: .. case 9: instead of case 0 .. 9: Or case [0..10]: ? Compatible to how list slicing works. Ah yes, bikeshed issue, but my solution is more beautiful. Also, Walter, did you ever think about doing something about the fall-through-by-default issue? Of course in a way that preserves C compatibility.
Re: dmd 1.046 and 2.031 releases
Tim Matthews wrote: grauzone wrote: Walter Bright wrote: のしいか (noshiika) wrote: Thank you for the great work, Walter and all the other contributors. But I am a bit disappointed with the CaseRangeStatement syntax. Why is it case 0: .. case 9: instead of case 0 .. 9: Or case [0..10]: ? Compatible to how list slicing works. Ah yes, bikeshed issue, but my solution is more beautiful. Also, Walter, did you ever think about doing something about the fall-through-by-default issue? Of course in a way that preserves C compatibility. Do u mean this http://digitalmars.com/d/2.0/statement.html#FinalSwitchStatement No. Also, this final switch feature seems to be only marginally useful, and normal switch statements do the same, just at runtime. So much for more pressing issues but it's his language and not mine so I'll shut up.
Re: dmd 1.046 and 2.031 releases
You are just saying it's ugly. I don't think it's ugly. Walter doesn't think it's ugly. Other people don't think it's ugly. Many of the people who said it's ugly actually came up with proposals that are arguably ugly, hopelessly confusing, or both. Look at only some of the rehashed proposals of today: the genial case [0 .. 10]: which is horribly inconsistent, and the awesome case 0: ... case 10:, also inconsistent (and gratuitously so) because ellipses today only end lists without having something to their right. The authors claim those are better than the current syntax, and one even claimed beauty, completely ignoring the utter lack of consistency with the rest of the language. I don't I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y). Other than that, I realize it's not that good of a choice and it's not elegant at all. But I think it's still better than some of your horrible language crimes (including yours) that are being forced into D. In any way, I think we should completely redesign the switch statement and give it a different syntax. No more C compatibility. No more Duff's device. We can keep the old switch statement for that.
Re: dmd 1.046 and 2.031 releases
In any way, I think we should completely redesign the switch statement and give it a different syntax. No more C compatibility. No more Duff's device. We can keep the old switch statement for that. PS: we could add awesome stuff like pattern matching to this, which would make D much more functional language like, which seems to be the new cool thing to do. We can also omit case labels completely, which will reduce repeated typing of keywords.
Re: Serialization for D. Comments, please!
BCS wrote: The demarshaller function is indexed via a string derived from the original object. What would the marshaller function key on? The best I can think of right now is the typeinfo and as of now, that's broken under DLLs DLLs are broken in general. There are many more problems associated with them, and you won't be happy with them. I write all my code with the assumption in mind, that TypeInfos/ClassInfos for the same type always are the same instance.
Re: Serialization for D. Comments, please!
BCS wrote:
Reply to grauzone,
BCS wrote:
The demarshaller function is indexed via a string derived from the
original object. What would the marshaller function key on? The best
I can think of right now is the typeinfo and as of now, that's broken
under DLLs
DLLs are broken in general. There are many more problems associated
with them, and you won't be happy with them. I write all my code with
the assumption in mind, that TypeInfos/ClassInfos for the same type
always are the same instance.
On second pass, even putting DLLs aside, I can't count on typeinfo being
the same in both sides because I can't even count on them being in the
same process, exe or even under the same compiler, OS or CPU.
For that, you had to write the TypeInfo pointer into the serialized data
stream, which obviously is not going to work. Obviously, you need some
type identification, which is independent from the compiled program binary.
But in-memory, using TypeInfo/ClassInfo as unique identifier is no
problem. Except if you somehow got 2 or more D runtimes in your process.
That's only possible when using the broken DLL support. Use DDL instead.
Can you get the mangled name of an object instance at runtime via typeinfo?
Not that I know of. IMHO, ClassInfo.name() is good enough.
But if you don't like it, just keep using mangleof. You obviously have
compile time access to the serializeable type, e.g.:
char[][ClassInfo] TypeMangledNames;
template SerializeMixin() {
static this() {
TypeMangledNames[typeof(this).classinfo] = typeof(this).mangleof;
}
}
Re: Serialization for D. Comments, please!
BCS wrote: Well, I can switch the default but, in my experience, most of the time repetition doesn't matter. I also dissagree on the relatively useless Oh really? I haven't used a graph data structure in some time. Most of them have been trees. And the cases I can think of, the repeated reference bit has been central the the structure so the chances of getting it wrong (or of missing it under test) are about nil. IMO, most tree-like structures are still full graphs in memory, because they often contain parent pointers, or point back to a parent indirectly (e.g. even if a generic tree data structure is implemented without parent pointers, the data element itself might contain such pointers). OTOH pointers to struct are not value types... Pointers are a whole different thing. A pointer can still point to a value type, because that struct might be embedded within an object (a class member that's a struct). interfaces are not supported either. But supporting interfaces would be very simple. It wouldn't be hard in the current form (you would add a mixin to the interface as well) but the non-mixin, outside in approach would have all sorts of interesting issues like how to get the correct sterilizer function. Huh? You can simple cast the interface to an object. And then cast the object to the serializeable type. You need to be able to do that anyway, because object references can be of the type Object, and there's no way you'd add your serialize mixin to Object. Also, is you writing sterilizer a typo or not?
Re: Serialization for D. Comments, please!
Huh? You can simple cast the interface to an object. That is not safe. not all interface instances are D objects. There are people who care for COM and C++ interfaces? COM is Windows specific, and C++ vtables are... uh, I don't know, platform/architecture/compiler vendor specific? In any case, serializable objects shouldn't contain references to such interfaces in the first place. And that just brought up another issue: how do you serialize a class that only ever shows up as a base class reference? The lib has no way to /find/ the type at compile time so it has no way to generate code to deal with it. But you already handle this. One of your mixins contains a static this ctor (which, btw., makes it impossible to use serializable types in cyclic dependent modules). It seems right now this ctor is only for registering the demarshaller function, but the same can be done with the marshaller function.
Re: Serialization for D. Comments, please!
BCS wrote: That's why I'd still require types to be marked as serializeable by the programmer. How would you do that aside from mixins? Make the user implement a marker interface, or let him provide a (single) special class member which fulfill the same function, or introduce annotations into the language. As far as marking goes, a mixin would be OK too, but as I said, I don't like adding arbitrary members into the user's scope without the user knowing. At least for all those structs, it's truly annoying and unneeded. Having to use different mixins for structs/classes sucks even more (wouldn't be required if you wanted). It isn't required, the difference is not struct vs. class but do you care about repeated references to instances of this type? IMHO a relatively useless optimization, that will only confuse the user. It will introduce subtle bugs if objects accidentally are repeated instead of serialized only once. By the way, how are you going to solve the other problems when serializing D types? Here are some troublesome types: - pointers? class references are pointers, for struct and what not, I'll just use a similar approach That's not really the problem here. You have no idea where a pointer points to. Is it a pointer to a new'ed memory block? Does it point into an object? Does it point into an array? Into the data segment? The GC provides no API to find out. You may be able to handle some cases above, but not all. - function pointers? - delegates? I won't Forces the user to use interfaces instead of delegates. - unions? for those I'll provide a way for the user to define the serialization themselves. - deserializing members that are const/immutable? D1, when I get to that; the same way you generated them anywhere else? I might even go with unsafe casts as I can be sure to get that correct. In D1, it comes for free: you simply don't need to handle it. But yes, it looks like you have to use dirty tricks in D2. - referential integrity across arrays and slices? I won't I wonder if anyone (I mean, especially user of a serialization library) would disagree with that choice. Sure, there are valid D programs that would break with this, but is relying on this really clean? author, I'm comfortable with them saying just do everything, but if someone else is doing it, that is likely to get feet shot off. If I made a generic any type function, it would recur into any referenced types and either spew a big list of type that it's dealing with (that people won't look at) or give no warning that it's walking into new territory and that it may not be doing valid operations. I didn't understand the last sentence. First off there is not enough information to correctly generate sterilizers for types. So the user has to do some thinking for most types. How do I make the user thinks about how and for what types code is being generated? Option 1) have the template run a paramg(msg,T.stringof) for each type and hope the user don't just ignore the list. Option 2) do nothing and be sure the user won't see anything. Option 3) Make the user write per type code and error when they don't. Oh, you mean if there are types in the object graphs the serializer can't deal with it? But how would option 2) work?
Re: Serialization for D. Comments, please!
BCS wrote: introduce annotations into the language. NO, not an option. What, why? Sure, this is not a realistic option. Well, I can switch the default but, in my experience, most of the time repetition doesn't matter. I also dissagree on the relatively useless Oh really? optimization bit, it adds some not exactly trivial overhead in about 3 or 4 different places. Maybe it costs a hash table lookup, but apart from that, you're saving space and time for marshaling additional instances. Of course, this is different with structs. But structs are value types. - function pointers? - delegates? I won't Forces the user to use interfaces instead of delegates. interfaces are not supported either. But supporting interfaces would be very simple.
Re: Serialization for D. Comments, please!
tupleof _can_ access private members, even if the type is from a different module than the function that uses the tupleof. This changed somewhere between dmd 1.030 and 1.040, I think. If it can, I would consider that a bug. It would be nice to get an official statement. And even if Walter sanctions it, I wont use it because I'm very leery of generating a system that automaticly reaches in from the outside and mucks with private members. Whoever makes a type serializeable needs to put at least some thought into how to serialize it. If it is the type's That's why I'd still require types to be marked as serializeable by the programmer. But using mixins and adding unknown members from the serialization machinery isn't that clean either. At leasr for all those structs, it's truly annoying and unneeded. Having to use different mixins for structs/classes sucks even more (wouldn't be required if you wanted). By the way, how are you going to solve the other problems when serializing D types? Here are some troublesome types: - pointers? - function pointers? - delegates? - unions? - deserializing members that are const/immutable? - referential integrity across arrays and slices? Also, it seems I just spotted a bug: floating point numbers loose precision as they are formatted with %s. author, I'm comfortable with them saying just do everything, but if someone else is doing it, that is likely to get feet shot off. If I made a generic any type function, it would recur into any referenced types and either spew a big list of type that it's dealing with (that people won't look at) or give no warning that it's walking into new territory and that it may not be doing valid operations. I didn't understand the last sentence.
Re: Serialization for D. Comments, please!
BCS wrote: the latest and greatest: http://arrayboundserror.blogspot.com/2009/06/serialization-for-d-part-6-of-n.html This time I'm hoping for some feedback on how people want to interface with 3rd party types. Is there any real reason for all those mixins?
Re: Serialization for D. Comments, please!
Is there any real reason for all those mixins? which ones? All used by the user. That would be Serializable and SerializableRecuring.
Re: Serialization for D. Comments, please!
BCS wrote: Reply to grauzone, Is there any real reason for all those mixins? which ones? All used by the user. That would be Serializable and SerializableRecuring. What else would you use? I guess if I really wanted to I could use the same device as for 3rd party types, but that just pushes the mixin to global scope (the functions have to be defined in the same module as the type or they won't be able to access private members) and introduces unneeded performance issues from using function pointers. If you can spot a better solution, I'm all for it, but I don't see one and don't think this solution is to bad. tupleof _can_ access private members, even if the type is from a different module than the function that uses the tupleof. This changed somewhere between dmd 1.030 and 1.040, I think.
Re: OT: Flash and Javascript (Was: Taunting)
Alexander Pánek wrote: grauzone wrote: browsers. What's the big deal everyone have with Javascript? It's unnecessary, annoying, slower, and adds security holes. When using Firefox, I usually use NoScript to block all scripts by default. Sometimes, some minor things don't work, and I have to enable JS. Now it's really rare to see functionality that couldn't be provided without JS. Rather, web designers seem to be really dumb and do stuff like replacing real links by script functions. As a prime example take YouTube. It's like YouTube doesn't believe in a life without AJAX! The simplest things don't work anymore. What for? About AJAX, you know it breaks the back button and all other sorts of practical things you are used from normal web browsing. And occasionally, they use it for animations. Animations what for? They only introduce artificial GUI latency. (You know, Win 3.11 feels faster.) A related example for annoying AJAX things are those applet like boxes, that contain a loading gif, and apparently loads a HTML subtree using AJAX. For completely over-engineered AJAX waste look at the Tango docs on dsource. I mean, it emulates frames, and the end result is worse than with good old frames! Ah yes, we all know frames are outdated, but AJAX is hip and new! Let's emulate frames, because we feel it's too slow to reload the whole page again! (Now now, I wonder if the Tango docs even require a webserver. Maybe that's the reason why there's no downloadable documentation? But maybe I'm blaming the wrong thing here.) They told use not to use blink or marquee? OK, we'll just use JS! Among the best uses of JS I've seen are snow flakes moved by a script. /rant (I feel better now.) Look mah, JS and Flash combined in shiny modal windows: http://www.smashingmagazine.com/2009/05/27/modal-windows-in-modern-web-design/ No, I really don’t want to torture you. Well, maybe a little. :P Oh god... why...
Re: OT: Flash and Javascript (Was: Taunting)
Alexander Pánek wrote: grauzone wrote: Alexander Pánek wrote: grauzone wrote: browsers. What's the big deal everyone have with Javascript? It's unnecessary, annoying, slower, and adds security holes. When using Firefox, I usually use NoScript to block all scripts by default. Sometimes, some minor things don't work, and I have to enable JS. Now it's really rare to see functionality that couldn't be provided without JS. Rather, web designers seem to be really dumb and do stuff like replacing real links by script functions. As a prime example take YouTube. It's like YouTube doesn't believe in a life without AJAX! The simplest things don't work anymore. What for? About AJAX, you know it breaks the back button and all other sorts of practical things you are used from normal web browsing. And occasionally, they use it for animations. Animations what for? They only introduce artificial GUI latency. (You know, Win 3.11 feels faster.) A related example for annoying AJAX things are those applet like boxes, that contain a loading gif, and apparently loads a HTML subtree using AJAX. For completely over-engineered AJAX waste look at the Tango docs on dsource. I mean, it emulates frames, and the end result is worse than with good old frames! Ah yes, we all know frames are outdated, but AJAX is hip and new! Let's emulate frames, because we feel it's too slow to reload the whole page again! (Now now, I wonder if the Tango docs even require a webserver. Maybe that's the reason why there's no downloadable documentation? But maybe I'm blaming the wrong thing here.) They told use not to use blink or marquee? OK, we'll just use JS! Among the best uses of JS I've seen are snow flakes moved by a script. /rant (I feel better now.) Look mah, JS and Flash combined in shiny modal windows: http://www.smashingmagazine.com/2009/05/27/modal-windows-in-modern-web-design/ No, I really don’t want to torture you. Well, maybe a little. :P Oh god... why... *snip* “The modal window has many advantages. For example, when a modal window contains a smaller element, the user doesn’t need to load an entirely new page just to access it (another way to achieve the same effect is e.g. by using AJAX-based tabs). By providing modal windows, you improve the usability of your website. Having to load pages over and over will annoy most users, so avoiding that is definitely a good thing. Modal windows also allow you to save space by getting rid of large elements that don’t need to be on the main page. For example, rather than putting a full video on a page, you can just provide a link, thumbnail or button of some sort.” Yeah, I read that. I want to smash him to pieces. Because. ;)
Re: Taunting
Give me a break. You guys act like it's a fucking affront to your religion to have to use Flash or Youtube. Sorry for complaining about the necessity to be forced to install an annoying, crappy, utterly obnoxious plugin like Flash, that barely adds functionality to anything, but instead makes everything slower, harder to use, and you have to figure out things like disabling sounds and tracking Flash cookies. It has some nice additional security holes too. (Oh my, is that what the Internet has become...?)
Re: OT: Flash and Javascript (Was: Taunting)
browsers. What's the big deal everyone have with Javascript? It's unnecessary, annoying, slower, and adds security holes. When using Firefox, I usually use NoScript to block all scripts by default. Sometimes, some minor things don't work, and I have to enable JS. Now it's really rare to see functionality that couldn't be provided without JS. Rather, web designers seem to be really dumb and do stuff like replacing real links by script functions. As a prime example take YouTube. It's like YouTube doesn't believe in a life without AJAX! The simplest things don't work anymore. What for? About AJAX, you know it breaks the back button and all other sorts of practical things you are used from normal web browsing. And occasionally, they use it for animations. Animations what for? They only introduce artificial GUI latency. (You know, Win 3.11 feels faster.) A related example for annoying AJAX things are those applet like boxes, that contain a loading gif, and apparently loads a HTML subtree using AJAX. For completely over-engineered AJAX waste look at the Tango docs on dsource. I mean, it emulates frames, and the end result is worse than with good old frames! Ah yes, we all know frames are outdated, but AJAX is hip and new! Let's emulate frames, because we feel it's too slow to reload the whole page again! (Now now, I wonder if the Tango docs even require a webserver. Maybe that's the reason why there's no downloadable documentation? But maybe I'm blaming the wrong thing here.) They told use not to use blink or marquee? OK, we'll just use JS! Among the best uses of JS I've seen are snow flakes moved by a script. /rant (I feel better now.)
Re: OT: Flash and Javascript (Was: Taunting)
Adblock is essential. Most ads have gotten so completely out-of-hand, I seriously wouldn't even be using the web anymore if it weren't for Adblock. Definitely. It's also useful for blocking other obnoxious stuff like emoticons or avatars in those phpBB forums. IIRC, I think NoScript does let you do site-by-site, right? I just hope it plays nice with QuickJava though, (or contains QuickJava-style Yes, disabling site-by-site is a major feature of NoScript. NoScript places an icon on the status bar. Clicking that icon will show a pop up menu, where you can choose which scripts to enable (by site), and if you want to do it permanently. I don't know how it plays with QuickJava, Java applets, or Flash. My only concern with NoScript is, enabling a site reloads all tabs containing a script from that site. Oh, and by default, it shows some sort of GUI animation when loading a site with blocked scripts. But you can disable it.
Re: OT: Flash and Javascript (Was: Taunting)
What browser are you *using*? Firefox. But I often use Konqueror for serious work (!= entertainment, wasting time). With Konqueror, some sites become dead slow with Java Script enabled. Oh, and although Konqueror is a very nice browser, scripting often causes malfunctions. That all just shows how fragile the approach of running scripts inside the browser is. It's probably Konqueror's fault, but if JS weren't so complicated (I mean, it's a complete scripting language), this wouldn't be an issue. Lots of complex software = more failures and performance regressions.
Re: OT: Flash and Javascript (Was: Taunting)
to get a new machine? They're like $12 now. Where can I buy 12$ computers?
Re: OT: Flash and Javascript (Was: Taunting)
Saaa wrote: My only concern with NoScript is, enabling a site reloads all tabs containing a script from that site. Oh, and by default, it shows some sort of GUI animation when loading a site with blocked scripts. But you can disable it. As you can disable the reloading ;) Thanks. And going over the options dialog, I noticed it can block Flash and Java, too. Now now, needing additional software just for disabling features is really... stupid, but at least I'm not using virus scanners or personal firewalls.
Re: OT: Flash and Javascript (Was: Taunting)
Jarrett Billingsley wrote: On Sun, May 24, 2009 at 5:12 PM, grauzone n...@example.net wrote: to get a new machine? They're like $12 now. Where can I buy 12$ computers? lern2hyperbole. Needing brand new PC hardware for using heavy websites is not really an exaggeration, though. As soon as you have several instances of that website loaded (in different browser windows, tabs, etc.), things are _definitely_ starting to get no fun, even with an overclocked, 64 bit water cooled octa core.
Re: Taunting
BCS wrote: Reply to Ary, http://www.youtube.com/watch?v=rtYCFVPfx4M The clunk you just heard is my jaw bouncing on the floor G NICE! It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system. Even if I spent hours configuring Eclipse for my needs, there's still the speed issue. Even after I purchased a new PC, using Eclipse felt like stirring lava. (Sure, it was better than before, but I'll just stay with my light-speed fast syntax highlighting text editor.) But for someone who does use Eclipse/Descent, this is great, of course.
Re: Taunting
It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system. I meant to write big, not bug. Talk about Freudian Slips!
Re: Taunting
Daniel Keep wrote: grauzone wrote: Saaa wrote: grauzone n...@example.net wrote in message news:gv4p44$1jq...@digitalmars.com... Ary Borenszweig wrote: http://www.youtube.com/watch?v=rtYCFVPfx4M How about posting a link to something everyone can play? Like an actual video file? Thank you. Isn't youtube a video upload site with an inbuilt player? Yes, but it requires Flash and an unholy amount of AJAX. No one can be bothered with installing Flash and having a JavaScript enabled browser, when something like mplayer would be enough. Especially if the media player works _much_better_. Obviously the large number of people using such sites are trying to prove you wrong. :P They just don't know it better. They probably think their PC isn't fast enough for fullscreen video playback and so on. Maybe they don't even know what's making their web browsers / websites so slow. And what component is responsible for playing ads with SOUND. To be fair, the alternatives aren't much better. Embedding a WMV or MOV is even more annoying, and Java's just a tremendous pain in the arse. It'd be nice if the current efforts to standardise video in HTML5 could do away with Flash video et al, but I'm not holding my breath on that. There's no technical reason why YouTube couldn't provide a download link for the hidden flv/mp4 file the flash player loads. Actually, there _was_ one video, where YouTube provided a direct link, but that was an exception. In fact, hiding the link to the actual video file seems to be some kind of soft DRM. Like all almost kinds of DRM, it's breakable, but it requires an effort 0. I don't want to support this. (And for video sites like YouTube, I'm not actually missing anything.) download youtube video Can't see a download button anywhere on YouTube. Obviously, Google forces users to install Flash. Possessing a burning hatred of Flash isn't going to get everyone else to stop using it. If that worked, we'd have killed off IE6 years ago. Firefox had tremendous success as IE replacement. If you want to go that far, Flash had success as Java replacement. Anyway, I'm not really fond of the idea of foreign, unknown programs running in my web browser. If you think about it, it's ridiculous. At least from the security point of view. Either build a better system and get it installed on 90% of the world's PCs or learn to live with it. :P There are dozens of open source video players. Projects like ffmpeg provide good backends for audio/video decoding. And I think even the builtin Windows Media Player can play mp4. -- Daniel
Re: Taunting
Yes, heaven forbid Ary spends his time adding and improving features when he should be building a new editor from the ground up. That's not what I'm saying. First, he's free to do with his time whatever he chooses to. Second, I think it'd be better to decouple debugger and editor. For example, I'd like to use this feature without having to use an entire IDE. Wouldn't it be great to have a free choice what components to use? Of course, that's only theory. In practice, it's simpler to built on an existing framework, GUI, and so on. And Ary is actually in favor of the fat-IDE-approach. I mean, that's fine, I don't expect him to change anything about this and I respect his opinion. In all seriousness, I hate IDEs because they are big, slow, and waste vast tracts of prime monitor space. But I'm willing to put up with that for Descent's compile-time view and (hopefully soon) compile-time debugging. If I could get that in a super fast, light programming editor, I'd use that instead. But I can't. As I said, I don't like all-in-one components. Except if it's really a holy grail of an IDE (by definition, everything would be perfect). But yeah, you can't have that. Thus it'd be better to split functionality and features across different pieces of software. Although it is annoying when I'm out and about on my little netbook and can't use Eclipse. C'est la vie.
Re: Taunting
Ary Borenszweig wrote: http://www.youtube.com/watch?v=rtYCFVPfx4M How about posting a link to something everyone can play? Like an actual video file? Thank you.
Re: dmd 1.045 / 2.030 release
* added .typeinfo to ClassInfo Very nice. Maybe I can go remove some hacks from my code now...
Re: dmd 2.029 release
Simen Kjaeraas wrote:
grauzone wrote:
void streamOut(T, R)(T object, R range)
{
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
So, um... what is a b c and T object?
In my opinion, this is a confusing example. I believe it was meant to be:
void streamOut(T, R)(T object, R range)
{
foreach(x; object.a) range.put(x);
range.put(object.b);
range.put(object.c);
}
So, streamOut is a free function, which it normally would not be. Now,
consider this:
struct foo {
int[] a;
bool b;
char c;
void streamOut(R)(R range) {
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
}
I believe this is what you'd normally do.
Do note that I might have misinterpreted it all, as Andrei's code would
not do what I have outlined above, I only feel it makes the most sense.
Yeah OK, but what about virtual functions? Not having it virtual is a
real disadvantage, because subclass-parts aren't automatically dumped.
What exactly is R, and why is it simpler than a Sink delegate? A Sink
delegate is as simple as it gets, and what else than a string do you
want to output? (Hint: this is probably not supposed to be a
serialization framework.)
One thing that I could imagine that put() automatically takes care of
formatting various data types into a string. Okay, where can I pass
format specifiers? What if put() can't deal with the type? Or does it
call std.string.format() anyway? Then why the indirection through the
string? Why not call format() directly? (Yes, format() needs to be able
to output using a sink instead of returning a string.)
Oh by the way, unlike a weird template, sink works with virtual methods,
too.
I have the impression Andrei wants to cast everything into ranges
instead of adhering to KISS.
--
Simen
Re: dmd 2.029 release
Andrei Alexandrescu wrote: grauzone wrote: Simen Kjaeraas wrote: Do note that I might have misinterpreted it all, as Andrei's code would not do what I have outlined above, I only feel it makes the most sense. Yeah OK, but what about virtual functions? Not having it virtual is a real disadvantage, because subclass-parts aren't automatically dumped. Streaming out is a virtual function that takes a classic interface object. (I explained that in two posts.) There were a lot of posts in this thread. From what I've gathered, what you said wasn't really concrete. Not as concrete as the sink proposals. What exactly is R, and why is it simpler than a Sink delegate? A Sink delegate is as simple as it gets, and what else than a string do you want to output? (Hint: this is probably not supposed to be a serialization framework.) It is simpler than a Sink delegate because the delegate is not simple; it's simplistic. You can't use std.algorithm with a delegate, it only accepts one type (meaning it is very inefficient if you have multiple types to output) - it's essentially a non-design. At some point, you need to format it to a string anyway. And it's probably not favorable to move that code into some deeply buried library code, because then you don't have full control over formatting. Anyway, I don't quite understand what you want to do. We were talking abou improving toString, right? One thing that I could imagine that put() automatically takes care of formatting various data types into a string. Okay, where can I pass format specifiers? What if put() can't deal with the type? Or does it call std.string.format() anyway? Then why the indirection through the string? Why not call format() directly? (Yes, format() needs to be able to output using a sink instead of returning a string.) I'd spend more time on explaining that but I fear you want more to convince yourself and others that output streams are no good and that your non-design is simpler, than actually getting answers to your questions. It's not my design, and I didn't even come up with that proposal. Come on, I know my tone and my posts is bitchy as hell, but flaming is not really what I'm up to. Oh by the way, unlike a weird template, sink works with virtual methods, too. I have the impression Andrei wants to cast everything into ranges instead of adhering to KISS. I want to adhere to KISS, and therefore I want to support output ranges with e.g. strings and files. If you don't take the time to look at ranges as you yourself said, then why do you spend time commenting on them? Shouldn't things go the other way? Oh, I look at the Phobos docs as it seems necessary. But I still might not know to the fullest how the pieces fit together and so on. Andrei
Re: dmd 2.029 release
No! rant toString() is one of the most dreadful features in D. Trying to slightly improve it is a waste of time -- the whole concept needs to be redone. It's horribly inflexible, tedious, and hugely inefficient. What more could there be to hate? Hey, it's only meant for debugging! (At least I hope.)
Re: dmd 2.029 release
Andrei Alexandrescu wrote:
grauzone wrote:
Yes. The way it should be is not with sink, but with the standard
output iterator method put().
void streamOut(T, R)(T object, R range)
{
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
Eh. Is a sink callback too simple and easy to use or what?
?
Why make it more complicated than it has to be?
Also, I don't know ranges, but your example doesn't seem to make much sense.
Andrei
Re: dmd 2.029 release
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Yes. The way it should be is not with sink, but with the standard
output iterator method put().
void streamOut(T, R)(T object, R range)
{
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
Eh. Is a sink callback too simple and easy to use or what?
?
Why make it more complicated than it has to be?
I am making it simpler.
How is it simpler?
sink(): simple delegate with the signature void delegate(char[] data);
output range: um what...? yeah, I know it has a put() method that
takes... something. What exactly is it supposed to take in your example?
Is streamOut() a method of the object to be dumped? What exact types to
T and R have? (You need the exact type if streamOut is supposed to be a
member function, and thus has to be virtual, so that you can it use like
the Object.toString method.)
Also, I don't know ranges, but your example doesn't seem to make much
sense.
s/but/consequently/
Probably. Just imagine you had to explain it to someone who's new to D.
Actually, I _am_ new to D2.0.
So, um... what is a b c and T object?
Andrei
Re: dmd 1.043 alpha for FreeBSD 7.1
Yay! But every time you give, we demand more. Where's dmd for 64 bit platforms?
Re: Cristian Vlasceanu and D for the .NET platform
BCS wrote: Reply to Walter, http://www.reddit.com/r/d_language/comments/838lf/cristian_vlasceanu_a nd_d_for_the_net_platform/ His comments on array slicing are interesting. Seems to me the solution should be to have *all* dynamic arrays be ArraySegment as all dynamic arrays under DMD are a slices of the full memory space. Whatever happened to T[new]. Seems The Gods prefer having something like an array builder struct, and leave slices unchanged. Or maybe they'll remove the ability to increase the length of a slice.
Re: Open source dmd on Reddit!
Ary Borenszweig wrote: Michel Fortin escribió: On 2009-03-06 14:35:59 -0500, Walter Bright newshou...@digitalmars.com said: Andrei Alexandrescu wrote: Can't live without bitfields! Give me bitfields and I'll lift the Earth! Here they are, std.bitmanip. Well-defined and more portable and flexible than C's. Meh, don't like the definition syntax. Classic. Well, he certainly has a point. Compare this: mixin(bitfields!( uint, x,2, int, y,3, uint, z,2, bool, flag, 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable. Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned. While I don't care very much about bitfields, that mixin(tmpl!(...)) syntax is awful. mixin tmpl!(...) is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins? Well, now the \ is character if free: \bitfields( unit, x, 2, int, y, 3, uint, z, 2, bool, flag, 1, ); But I think it looks ugly: the \ is lambda in some languages and this also reminds me of LaTeX... :-P String mixins are awful in the first place. The only thing that could save this kind of thing are AST macros.
Re: QtD 0.1 is out!
Lars Ivar Igesund wrote: Eldar Insafutdinov wrote: We faced a bug that module static constructors don't work with cyclic imports. Currently it's fixed with a dirty hack which is not really acceptable. Is there any chance for this to be fixed? IMO it is the cyclic import that is the bug ;) Maybe all cyclic dependency bugs are on purpose, to teach people not to use this evil D feature? Yeah, that must it be. I can't explain why else these bugs/issues aren't fixed, and why people only reply with incredibly useful statements like but you shouldn't use this feature anyway!. Broken features should be either fixed or removed. This half-assedness about it isn't really going to help D.
Re: QtD 0.1 is out!
Jarrett Billingsley wrote: On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed. Anyway, I tried to place enums outside the classes, and I got: qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced Circular import is present. You would do well to remove all circular imports. They make the compiler do stupid things. I really wonder why Walter doesn't just forbid circular dependencies in the language spec.
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
But... why Javascript hurts you that much? What did it do to you? Yesterday, I was on digitalmars.com, browsing the archive for the D newsgroup. Actually, I just had it open in a tab, and was actively browsing another website. I wondered why the browser had such a bad response. Finally, I figured out, that the cause was some JavaScript code included from Amazon. It showed some applet on the bottom of the archive page, and it didn't even work. All it did was displaying some loading gif animation and eating CPU. When I blocked Amazon, all was fast and responsive again. Another example is Candydoc. That tree on the left is awful JavaScript hackery. It only works if JS is enabled, and even then it is slow, annoying to use, and all that. Candydoc advertises itself as Produced result is AJAX web-application that is compatible with all mainstream web browsers. Without AJAX, the authot of Candydoc would have done a much better job. Now isn't that typical? (By the way, AJAX for offline browsable documentation? What?) And sorry, I can't stop my rant. Did you ever see those polls, which are mostly added on the left or right border of a webpage? Lately, I only see AJAX-style ones, and you can use them only with JavaScript enabled. When you vote, they show an animation, which alpha blends from one display state into another. Wheee, great. In the old days, you had to wait for the slow GUI to respond. Today, you wait for the GUI animation to finish. Both introduce a small but annoying delay. And not to forgot, when some dirty piece of AJAX JavaScript code runs wild. Then it will send HTTP requests in a loop, even though the page finished loading. Good that we have Noscript to trash the AJAX programmer's worthless effort. Sometimes I love new technology.
Re: QtD 0.1 is out!
Daniel Keep wrote: Eldar Insafutdinov wrote: David Ferenczi Wrote: I'm glad to see this release and the progress of qtd! Coudl you please provide a link to the tutrial? Many thanks! Eldar Insafutdinov wrote: It didn't take very long after previous post to make a first implementation of signals and slots(thanks to great people from #d) which means that you can actually start doing something useful. 0.1 is probably most suitable tag for this release. Again - see tutorials for how to use signals. tutorials are in trunk/examples http://code.google.com/p/qtd/source/browse/#svn/trunk/examples No files in this directory. Well that sucks. Oh well, I... hey, wait a second... *unblocks javascript* No files in this directory, but there ARE subdirectories! Sometimes, I really wish there was a way to electrocute people for making their sites break without Javascript... -- Daniel (Not angry at you, Eldar; angry at Google. They should know better :) ) Finally somehow who shares my pain. You have my sympathy. Especially Google is really bad with this. Not only are they pushing AJAX. They completely fail to make their sites useful without JS. Did you ever try to browse Youtube with JavaScript disabled? It's really fun to see, for what things they thought you _must_ have JS enabled. (My solution to this is not to browse Youtube at all.)
Re: QtD 0.1 is out!
Do I see correctly, that you didn't need to introduce a MOC compiler for D? And that the Signal and Slots implementation is written in pure D?
