Re: QtD 0.1 is out!
Frits van Bommel wrote: Walter Bright wrote: Christopher Wright wrote: Walter Bright wrote: Christopher Wright wrote: Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug. No, it does not. The compiler doesn't know about private imports of separately compiled modules. Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement. The problem if it detects it in an implementation-defined manner is the source code is no longer portable. ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error? Right. It's like the compiler warning you if your program starts with assert (false).
Re: QtD 0.1 is out!
Walter Bright wrote: Yigal Chripun wrote: this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly. D can do the same thing - it can use the source of the module directly, or it can use a hand-generated 'header' file, or an automatically generated 'header' file. The latter is semantically indistinguishable from compiling the source module to a metadata file. I originally considered having D write such a metadata file, until I realized I didn't have to invent a format and a writer and reader for that format. I could just use the D source code notation as a metadata file and reuse the existing code. The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect.
Re: QtD 0.1 is out!
On Sun, Mar 1, 2009 at 10:16 AM, Don nos...@nospam.com wrote: The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect. Yeah. Imagine if DMDFE were written in D; how big would those modules have to be?
Re: QtD 0.1 is out!
Jarrett Billingsley wrote: On Sun, Mar 1, 2009 at 10:16 AM, Don nos...@nospam.com wrote: The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect. Yeah. Imagine if DMDFE were written in D; how big would those modules have to be? The current organization of DMDFE is totally inconducive to D's module system, which I find ironic.
Re: QtD 0.1 is out!
Walter Bright wrote: Frits van Bommel wrote: Walter Bright wrote: The problem if it detects it in an implementation-defined manner is the source code is no longer portable. ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error? Nothing, it's just that the compiler cannot prove it is an error. Not even on a best-effort basis? It doesn't have to catch every possible case; I for one would be perfectly fine with it if it didn't catch the I omitted a private import from my .di file case...
Re: QtD 0.1 is out!
Frits van Bommel wrote: Not even on a best-effort basis? It doesn't have to catch every possible case; I for one would be perfectly fine with it if it didn't catch the I omitted a private import from my .di file case... Doing so would require full blown data flow analysis, which the front end is not equipped to do.
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!
Fawzi Mohamed wrote: On 2009-02-27 21:49:58 +0100, Fawzi Mohamed fmoha...@mac.com said: On 2009-02-27 21:10:29 +0100, Walter Bright newshou...@digitalmars.com said: Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit. I fully agree, *avoiding* circular dependencies between modules is in general a good practice: a circular dependency it means that you have tight coupling, in in that case it is normally better to have everything in the same module to have a better control on it. Sometime one has cases in which circular dependencies arise, two ways to get rid of them are for example: 1) define and interface, the circular dependency is in the interfaces that are described in the same module, the two (or more) modules include the interfaces, and are not directly dependent on each other (only through the interfaces) 2) use templates, the circular dependencies are on a template parameter. The circular dependencies arise only upon instantiation I agree with the above but there is still a small issue here: A module is a single file and when you have several large classes that are tightly coupled you can get a very big file with thousands of lines. what if i want to put each class in its own file? besides, the notion of a module is somewhat redundant - it's functionally a static struct. this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly.
Re: QtD 0.1 is out!
Jarrett Billingsley wrote: On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripunyigal...@gmail.com wrote: I agree with the above but there is still a small issue here: A module is a single file and when you have several large classes that are tightly coupled you can get a very big file with thousands of lines. what if i want to put each class in its own file? besides, the notion of a module is somewhat redundant - it's functionally a static struct. this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly. Precsely. I've been toying with the concept of a compiler which doesn't actually emit object files until it has to link its code into some form of executable. Instead it produces these sort of platform-independent internal representation files, which can contain all the metadata and symbol information needed. They can be as small as a single module or as large as an entire multi-level package. It sounds a lot like the model C# has adopted. I also think that source code organization should be orthogonal to the organization of the deployment executables (assemblies in .net) something simillar to namespaces in C#. other useful metadata to include in those files is the documantation and versioning info.
Re: QtD 0.1 is out!
Eldar Insafutdinov wrote: 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 ;) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango #D: larsivi Dancing the Tango I am not an expert but, Qt is a good example in my opinion, beause it is a mature API (fourth version) which shows that you can't go without cyclic dependencies in a very complex project. I do not agree that this proves anything. My opinion is that a circular dependency at the very least is a hazardous design decision. In a class hierarchy this may work out well if there never ever will be any sub-classes to the involved classes, but typically this will come back and bite you in the toe when you cannot afford to redesign. I know D is less forgiving about this than other languages, and so it is a good help in creating a good design. Note that Java allows circular import dependencies, but not class dependencies at construction time (instance variables initialised prior to the constructor being run) which is similar to the static construction restriction in D. I understand that your issue is due to Qt's design and not your own, and as such the compiler could be more helpful, but in general I think the compiler should flag this at least at warning level (I agree with those who think it should be a compile time rather than a runtime error). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango #D: larsivi Dancing the Tango
Re: QtD 0.1 is out!
On 2009-02-28 14:54:26 +0100, Christopher Wright dhase...@gmail.com said:
Lutger wrote:
grauzone wrote:
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.
Well it's about cyclic dependency of initialization via module
constructors only right? Cyclic imports in general aren't (supposed to
be) broken, nor are module constructors.
And in point of fact, you can modify the runtime so it will not throw
exceptions on cyclic dependencies:
Index: genobj.d
===
--- genobj.d(revision 4339)
+++ genobj.d(working copy)
@@ -1098,11 +1098,7 @@
if (m.ctor || m.dtor)
{
if (m.flags MIctorstart)
-{ if (skip || m.flags MIstandalone)
-continue;
-throw new Exception( Cyclic dependency in module ~
(from is null ? *null* : from.name) ~ for import ~ m.name);
-}
-
+ continue;
m.flags |= MIctorstart;
_moduleCtor2(m,m.importedModules, 0);
if (m.ctor)
This opens you up to certain bugs, but they should be relatively rare.
I've tried it, and it appears to work.
Tango has it (thanks to lindquist) your change removes it :)
Re: QtD 0.1 is out!
Yigal Chripun wrote: this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly. D can do the same thing - it can use the source of the module directly, or it can use a hand-generated 'header' file, or an automatically generated 'header' file. The latter is semantically indistinguishable from compiling the source module to a metadata file. I originally considered having D write such a metadata file, until I realized I didn't have to invent a format and a writer and reader for that format. I could just use the D source code notation as a metadata file and reuse the existing code.
Re: QtD 0.1 is out!
Christopher Wright wrote: Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug. No, it does not. The compiler doesn't know about private imports of separately compiled modules.
Re: QtD 0.1 is out!
On Sat, Feb 28, 2009 at 3:05 PM, Walter Bright newshou...@digitalmars.com wrote: Christopher Wright wrote: Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug. No, it does not. The compiler doesn't know about private imports of separately compiled modules. See it's funny, since in the other post, you said that using an autogenerated header file is semantically indistinguishable from compiling it to a metadata file. And here you're pointing out an obvious shortcoming!
Re: QtD 0.1 is out!
Jarrett Billingsley wrote: See it's funny, since in the other post, you said that using an autogenerated header file is semantically indistinguishable from compiling it to a metadata file. And here you're pointing out an obvious shortcoming! You can make hand-generated ones, too. The idea of keeping private imports private is to explicitly *avoid* dependencies on knowing the contents. It's a principle of encapsulization.
Re: QtD 0.1 is out!
On Sat, 28 Feb 2009 13:03:05 -0800, Andrei Alexandrescu wrote: Walter Bright wrote: Jarrett Billingsley wrote: See it's funny, since in the other post, you said that using an autogenerated header file is semantically indistinguishable from compiling it to a metadata file. And here you're pointing out an obvious shortcoming! You can make hand-generated ones, too. The idea of keeping private imports private is to explicitly *avoid* dependencies on knowing the contents. It's a principle of encapsulization. encapsuli...what? I definitedly need to conceptify that one :o). I think the word Walter was reaching for was encapsulement ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: QtD 0.1 is out!
Yigal Chripun wrote:
On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripunyigal...@gmail.com
wrote:
I agree with the above but there is still a small issue here:
A module is a single file and when you have several large classes
that are
tightly coupled you can get a very big file with thousands of lines.
what if
i want to put each class in its own file?
besides, the notion of a module is somewhat redundant - it's
functionally a
static struct.
You can do this with mixins or aliases.
Honestly, something I'd like to see is to extend the import syntax to
allow you to import symbols from other symbols. For example:
module foo;
struct bar
{
static void baz();
}
module main;
import foo.bar;
void main() { baz(); }
this is related to D's compilation model which is copied from C/C++
and it
seems to me that this model is outdated. C#'s model of assemblies and
metadata seems more capable. for instance there's no need for header
files,
that info is stored in the metadata of the assembly.
Given that D name mangling contains most if not all of a function's
interface, it sometimes makes me wonder why we can't just import a .lib
file.
Heck, stick an extra symbol on the end called _D_Interface if you must. :)
I also think that source code organization should be orthogonal to the
organization of the deployment executables (assemblies in .net)
something simillar to namespaces in C#.
There are times where I hate this. The problem is that this seems to
encourage very flat hierarchies in .NET code, with everything jammed
together. What really exacerbates the situation is that namespaces can
be added to by any library at any time.
For example, I had some code in C#, and I couldn't for the life of me
figure out what I was supposed to link to. Because the examples had
multiple libraries all dumping their stuff into the same namespace, it
was impossible to work out where any given symbol was coming from.
I ended up having to manually go through every goddamn library with the
object browser to figure it out.
Enforcing the module-file thing can be annoying at times, but nowhere
near as bad as having no indication whatsoever where something is defined.
-- Daniel
Re: QtD 0.1 is out!
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?
Re: QtD 0.1 is out!
On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov e.insafutdi...@gmail.com 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? I'll save Walter the trouble: come up with a reproduceable testcase if you haven't already. It won't get fixed it he can't tell what the problem is.
Re: QtD 0.1 is out!
Walter Bright Wrote: Jarrett Billingsley wrote: On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov e.insafutdi...@gmail.com 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? I'll save Walter the trouble: come up with a reproduceable testcase if you haven't already. It won't get fixed it he can't tell what the problem is. I'll add to that my experience is that if the test case is incomplete, then I need to guess at the rest and fill it in. Often, then the test case works, and there's a cycle of I can't reproduce the problem followed by the missing bit of context that was the real cause. Then once the problem gets fixed, the reproducible test case goes into the test suite so it stays fixed. I'm sorry, my mistake - it's in specs http://www.digitalmars.com/d/1.0/module.html Cycles (circular dependencies) in the import declarations are allowed as long as not both of the modules contain static constructors or static destructors. Violation of this rule will result in a runtime exception. Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent..
Re: QtD 0.1 is out!
Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit.
Re: QtD 0.1 is out!
Walter Bright Wrote: Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit. in our case resources we are initializing are unrelated to the modules we are importing. and semantically the code is placed in modules as it should be.
Re: QtD 0.1 is out!
On 2009-02-27 21:10:29 +0100, Walter Bright newshou...@digitalmars.com said: Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit. I fully agree, circular dependencies between modules is in general a good practice: a circular dependency it means that you have tight coupling, in in that case it is normally better to have everything in the same module to have a better control on it. Sometime one has cases in which circular dependencies arise, two ways to get rid of them are for example: 1) define and interface, the circular dependency is in the interfaces that are described in the same module, the two (or more) modules include the interfaces, and are not directly dependent on each other (only through the interfaces) 2) use templates, the circular dependencies are on a template parameter. The circular dependencies arise only upon instantiation
Re: QtD 0.1 is out!
On 2009-02-27 21:49:58 +0100, Fawzi Mohamed fmoha...@mac.com said: On 2009-02-27 21:10:29 +0100, Walter Bright newshou...@digitalmars.com said: Eldar Insafutdinov wrote: Now we have to make a manual init function called from class constructors. I understand that allowing static consructors with cyclic imports will make order of their execution undefined, but this is acceptable and actually semantically doesn't break the idea of cyclic imports. Otherwise in my opinion this behavior is inconsistent.. One of the goals of D is to eliminate undefined behavior wherever possible. In C++, the undefined order of static construction was a source of many porting problems. I think it's better in the long run to have a defined order, even if it means having to reorganize the code a bit. I fully agree, *avoiding* circular dependencies between modules is in general a good practice: a circular dependency it means that you have tight coupling, in in that case it is normally better to have everything in the same module to have a better control on it. Sometime one has cases in which circular dependencies arise, two ways to get rid of them are for example: 1) define and interface, the circular dependency is in the interfaces that are described in the same module, the two (or more) modules include the interfaces, and are not directly dependent on each other (only through the interfaces) 2) use templates, the circular dependencies are on a template parameter. The circular dependencies arise only upon instantiation
Re: QtD 0.1 is out!
Eldar Insafutdinov wrote: in our case resources we are initializing are unrelated to the modules we are importing. and semantically the code is placed in modules as it should be. True, often there isn't an actual dependency on the order, but the compiler can't tell that.
Re: QtD 0.1 is out!
On Fri, Feb 27, 2009 at 5:07 PM, Walter Bright newshou...@digitalmars.com wrote: Eldar Insafutdinov wrote: in our case resources we are initializing are unrelated to the modules we are importing. and semantically the code is placed in modules as it should be. True, often there isn't an actual dependency on the order, but the compiler can't tell that. I was going to say can't it? but then remembered separate compilation. Sigh. I think the separate compilation paradigm, at least as designed for C and C++, has to go the way of the dodo for lots of cool things to be made possible. The thread on .D about not being able to non-virtualize methods in the face of separate compilation is another example.
Re: QtD 0.1 is out!
qtd now works for windows. Here's the binary package http://qtd.googlecode.com/files/qtd-dmd-tango-win32.zip . It is compiled with dmd 1.036 and tango from trunk dated November 2008.
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Sun, Feb 22, 2009 at 5:27 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: qtd now works for windows. Here's the binary package http://qtd.googlecode.com/files/qtd-dmd-tango-win32.zip . It is compiled with dmd 1.036 and tango from trunk dated November 2008. Fantastic. Have you written anywhere how you eventually resolved the linker problems? --bb Actually it is a magic. Another guy wrote a makefile that is now building library. C++ part of binding sits in a dll, while D part is in static library. to access symbols from dll we use implib. So what he did, he combined implib output lib with D object files(I don't know how exactly, I didn't even look into makefile). So the linker bug didn't appear. Btw if somebody wants to build qtd from sources, he should modify makefiles - paths to Qt, etc. In couple of days we will make it more usable and make a written guide.
Re: QtD 0.1 is out!
What you and your crew are doing is really awesome! And you are beating all of the nasty linker errors and odd obstacles. Way to go. At some point in the future I will probably need to write cross-platform GUI apps in D, and I'll be looking to QT since it is good at this kind of work. So your work could potentially make my life much easier and my code much better at some point. Thanks. Keep up the good work and victory!
Re: QtD 0.1 is out!
We found out that while compiling qtd with dmd 1.038 and newer compiler hangs. ldc is also affected by this issue. which means that this is frontend bug. testcase is big of course. What are the possible options to solve this issue?
Re: QtD 0.1 is out!
On Sun, Feb 22, 2009 at 7:45 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: We found out that while compiling qtd with dmd 1.038 and newer compiler hangs. ldc is also affected by this issue. which means that this is frontend bug. testcase is big of course. What are the possible options to solve this issue? I think Walter has figured this one out. My code was hanging too, and I gave him some info off list that seemed to lead him to a resolution. --bb
Re: QtD 0.1 is out!
On Sun, 22 Feb 2009 08:04:12 +0900, Bill Baxter wrote: On Sun, Feb 22, 2009 at 7:45 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: We found out that while compiling qtd with dmd 1.038 and newer compiler hangs. ldc is also affected by this issue. which means that this is frontend bug. testcase is big of course. What are the possible options to solve this issue? I think Walter has figured this one out. My code was hanging too, and I gave him some info off list that seemed to lead him to a resolution. --bb Do you happen to know what bug report that is?
Re: QtD 0.1 is out!
On Sun, Feb 22, 2009 at 10:16 AM, Moritz Warning moritzwarn...@web.de wrote: On Sun, 22 Feb 2009 08:04:12 +0900, Bill Baxter wrote: On Sun, Feb 22, 2009 at 7:45 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: We found out that while compiling qtd with dmd 1.038 and newer compiler hangs. ldc is also affected by this issue. which means that this is frontend bug. testcase is big of course. What are the possible options to solve this issue? I think Walter has figured this one out. My code was hanging too, and I gave him some info off list that seemed to lead him to a resolution. --bb Do you happen to know what bug report that is? It was the one about compiling taking a long time that he was looking into, but it turned out that for my app it wasn't just taking a long time, it was getting stuck in an infinite loop. http://d.puremagic.com/issues/show_bug.cgi?id=2582 --bb
Re: LGPL Re: QtD 0.1 is out!
On Tue, Feb 17, 2009 at 7:06 AM, renoX reno...@free.fr wrote: naryl a écrit : Don Wrote: Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use. # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license. LGPL doesn't explicitly prohibits static linking. It serves to ensure that the modified library can be replaced by other version at any time. And there's a good reason for that. Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :) I disagree: the LGPL is probably the most 'derived' license: because developers don't like the stupid restriction on static linking they change it.. Well, there's another reason: the LPGL (at least version 2.1) is not exactly clear on the status of templates. Does instantiating a template create a derived work or not? This is also the reason why Qt Software/Nokia is currently still working on their modification of the GPL. The non-static restriction is probably built in for guaranteeing 'user freedom' with respect to the LGPLed code, but in practice it's a PITA for the user because it requires you to carry around a bunch of DLLs. Oh well :). All hail the Apache 2.0 license ;). Take care, Daniel
Re: QtD 0.1 is out!
Eldar Insafutdinov wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb Yes, it is this issue: Unexpected OPTLINK Termination at EIP=0041AFFD. And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently. Do you compile it with inlining on? Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining. Which file is it, anyway? --bb it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining. Ok. Is it some kind of automatically generated file? I don't see it in the qtd repo. --bb yes, all files are automatically generated. If you wish I can upload it(compiled binding with headers) somewhere. No, that's ok. I was just curious. So it sounds like the best hope is to try to find some way to split it up some. There must be some way it can be broken up, even if that requires turning some private members public. No? --bb It's in one file because of cyclic imports bug in dmd. The bug with optlink seems to be old, any chance that it's going to be fixed? Approximately zero chance. Optlink is entirely written in asm, and AFAIK Walter doesn't want to touch it. There's a much greater chance of the circular imports bug getting fixed -- it has to happen one day.
Re: QtD 0.1 is out!
On Sun, 15 Feb 2009 21:27:35 -0500, Eldar Insafutdinov
e.insafutdi...@gmail.com wrote:
Eldar Insafutdinov Wrote:
Max Samukha Wrote:
On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter wbax...@gmail.com
wrote:
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
samu...@voliacable.com.removethis wrote:
On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
e.insafutdi...@gmail.com wrote:
Finally we managed to compile qtd for Windows. But at the very last
step when compiling example, optlink crashed with a messagebox
containing X86 registers content. This seems to be a blocker for qtd
working on windows..
This may be related to the famous
http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't
make extensive use of templates.
It can also happen because of a single very large file. Perhaps one
created by some sort of automatic code generation. Anything like that
in qtd?
--bb
Yes, all modules are autogenerated. You are right, we probably should
think about splitting up that big file. For example, by placing enum
definitions into a separate module. It is still a less preferred
solution because it requires more tweaking of the original code
generator, which is already messy.
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.
You can still alias global enums into the class scope if you want Qt.A
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.
Taking them outside the class doesn't help. I proposed to put them in
a separate module. That would require renaming them to include class
names. Yes, that sucks but it seems there's not much choice.
module QFooEnums;
enum QFooState {}
module QBarEnums;
enum QBarState {}
module QFoo;
import QBar;
import QFooEnums;
import QBarEnums;
class QFoo
{
alias QFooState State; // if you really want to
void bar(QBarState e) {}
}
---
module QBar;
import QFooEnums;
import QBarEnums;
QBar
{
alias QBarState State;
void foo(QFooState e) {}
}
Or put all the enums in a single module (which will result in a big
file but more digestable for optlink)
Btw, circular imports magically erase static constructors from the
menu.
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: QtD 0.1 is out!
Eldar Insafutdinov wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. What you can do is try to obj2asm and dumpobj -p the .obj files, to see if those files are well-formed or not.
Re: QtD 0.1 is out!
Walter Bright Wrote: Eldar Insafutdinov wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. What you can do is try to obj2asm and dumpobj -p the .obj files, to see if those files are well-formed or not. I have never dealed with asm before and besides there are more than 200 files in the project, that would be crucial to check them all.
Re: QtD 0.1 is out!
Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
Re: QtD 0.1 is out!
On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates.
Re: QtD 0.1 is out!
On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb
Re: QtD 0.1 is out!
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha samu...@voliacable.com.removethis wrote: On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates. It can also happen because of a single very large file. Perhaps one created by some sort of automatic code generation. Anything like that in qtd? --bb
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb Yes, it is this issue: Unexpected OPTLINK Termination at EIP=0041AFFD. And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently.
Re: QtD 0.1 is out!
On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb Yes, it is this issue: Unexpected OPTLINK Termination at EIP=0041AFFD. And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently. Do you compile it with inlining on? Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining. Which file is it, anyway? --bb
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb Yes, it is this issue: Unexpected OPTLINK Termination at EIP=0041AFFD. And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently. Do you compile it with inlining on? Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining. Which file is it, anyway? --bb it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining.
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb Yes, it is this issue: Unexpected OPTLINK Termination at EIP=0041AFFD. And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently. Do you compile it with inlining on? Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining. Which file is it, anyway? --bb it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining. Ok. Is it some kind of automatically generated file? I don't see it in the qtd repo. --bb yes, all files are automatically generated. If you wish I can upload it(compiled binding with headers) somewhere.
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. Was this what you saw? Unexpected OPTLINK Termination at EIP=0044C37B http://d.puremagic.com/issues/show_bug.cgi?id=424 Whatever it was, chances are good it's a known bug. So it would be good to figure out which one it is that you're hitting exactly. --bb Yes, it is this issue: Unexpected OPTLINK Termination at EIP=0041AFFD. And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently. Do you compile it with inlining on? Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining. Which file is it, anyway? --bb it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining. Ok. Is it some kind of automatically generated file? I don't see it in the qtd repo. --bb yes, all files are automatically generated. If you wish I can upload it(compiled binding with headers) somewhere. No, that's ok. I was just curious. So it sounds like the best hope is to try to find some way to split it up some. There must be some way it can be broken up, even if that requires turning some private members public. No? --bb It's in one file because of cyclic imports bug in dmd. The bug with optlink seems to be old, any chance that it's going to be fixed?
Re: QtD 0.1 is out!
On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter wbax...@gmail.com wrote: On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha samu...@voliacable.com.removethis wrote: On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows.. This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates. It can also happen because of a single very large file. Perhaps one created by some sort of automatic code generation. Anything like that in qtd? --bb Yes, all modules are autogenerated. You are right, we probably should think about splitting up that big file. For example, by placing enum definitions into a separate module. It is still a less preferred solution because it requires more tweaking of the original code generator, which is already messy.
Re: QtD 0.1 is out!
On Mon, Feb 16, 2009 at 10:32 AM, 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. I guess we'll just have to wait for LDC then, because eliminating the too many fixups issue in OPTLINK is completely and utterly impossible. --bb ;-)
Re: QtD 0.1 is out!
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.
Re: QtD 0.1 is out!
Eldar Insafutdinov Wrote: This way won't really work because there are dozens of such a functions - that's for virtual dispatch. I have just solved it by declaring functions export extern (C) and adding _ prefix to function name when calling GetProcAddress. So technically there are no issues to make qtd working on windows! So porting qtd to windows almost finished, but I experienced couple of new problems. One of them is that these callback functions that I declare on D side(as export extern C) of the binding and that should be called from C++ part which sits in DLL, they are not put by linker into executable if they are in a static library. If I compile module which contains them with the resulting executable - it works fine, functions are in executable. I tried -L/-L/NOPACKFUNCTIONS but it didn't help. What can solve this problem? Thank you.
Re: QtD 0.1 is out!
Mike Parker Wrote: Eldar Insafutdinov wrote: naryl Wrote: Eldar Insafutdinov Wrote: I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work. You mean the Revised BSD License I presume? It's a subject to discuss. I am not good at licenses. The revised (or modified) BSD is the version most commonly used today. In my experience, when people say BSD License it's the one they are usually referring to. This is the version of BSD used for Derelict. As for the difference, the original BSD included a clause that required derived works to acknowledge the original work. The modified version has no such requirement. You can read more about it on Wikipedia[1]. I've looked at numerous open source projects over the years which were licensed under the BSD. I can't recall the last time I saw one using the original version. IMO, using the modified version is a no-brainer. [1] http://en.wikipedia.org/wiki/BSD_licenses Okey, if it is the most suitable license, we can go with it.
Re: QtD 0.1 is out!
On Thu, 12 Feb 2009 22:22:41 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? I believe it should be extern extern(C) ... Otherwise you /declare/ a function with C linkage but provide no implementation so that's why it fails at link time.
Re: QtD 0.1 is out!
Don Wrote: John Reimer wrote: Hello Eldar, Bill Baxter Wrote: On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Denis Koroskin Wrote: On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows. And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem.. You could use mingw's GNU make with CC=dmc. But I dunno if dmc will compile Qt or not. I would think it would, though. --bb Actually I decided to make a dll. It is possible to do it and will be more robust solution. Qt is not tested to be compiled with dmc by trolltech(mingw, msvc and icc are guaranteed). A dll is probably your best option, if you can make it work with the C++ code(?). I would have thought you needed a C interface, though. dmc is rarely supported by the majority of open-source projects out there, so you end up having to fix a lot of makefiles and a lot of code. It is especially difficult getting C++ code working with such projects because many of these will use macro definitions to enable/disable certain vendor compiler features. Also you will run into C++ implementation differences that make dmc choke. On several occasions where I've tried to use dmc for the same reason, and I've come to the conclusion that dmc support is a whole project in itself. It's a huge waste of time if all you want is to interface with a library. I recommend the ddl route if you can make it work. Most others have done the same. Incindentally, if you are curious why projects like Derelict and other bindings (using dynamic loading) are so oft used in the D community, this is pretty much the reason. -JJR Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use. # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license. I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work.
Re: QtD 0.1 is out!
Eldar Insafutdinov wrote: Don Wrote: John Reimer wrote: Hello Eldar, Bill Baxter Wrote: On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Denis Koroskin Wrote: On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows. And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem.. You could use mingw's GNU make with CC=dmc. But I dunno if dmc will compile Qt or not. I would think it would, though. --bb Actually I decided to make a dll. It is possible to do it and will be more robust solution. Qt is not tested to be compiled with dmc by trolltech(mingw, msvc and icc are guaranteed). A dll is probably your best option, if you can make it work with the C++ code(?). I would have thought you needed a C interface, though. dmc is rarely supported by the majority of open-source projects out there, so you end up having to fix a lot of makefiles and a lot of code. It is especially difficult getting C++ code working with such projects because many of these will use macro definitions to enable/disable certain vendor compiler features. Also you will run into C++ implementation differences that make dmc choke. On several occasions where I've tried to use dmc for the same reason, and I've come to the conclusion that dmc support is a whole project in itself. It's a huge waste of time if all you want is to interface with a library. I recommend the ddl route if you can make it work. Most others have done the same. Incindentally, if you are curious why projects like Derelict and other bindings (using dynamic loading) are so oft used in the D community, this is pretty much the reason. -JJR Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use. # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license. I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work. Cool!
Re: QtD 0.1 is out!
Eldar Insafutdinov Wrote: I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work. You mean the Revised BSD License I presume?
Re: QtD 0.1 is out!
naryl wrote: Don Wrote: Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use. # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license. LGPL doesn't explicitly prohibits static linking. It serves to ensure that the modified library can be replaced by other version at any time. And there's a good reason for that. Yes. But does ANYONE ever do that? It's an invitation to DLL hell. Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :) Exactly. That's why it's the lunatic license. The LGPL inconveniences everyone in order to preserve a freedom which benefits NOBODY. It feels to me like giving you a free car PROVIDED that you ensure that there is a coffee cup glued to the top of it at all times. I'm strongly in favour of the GPL (especially for apps), but the LGPL is pure lunacy.
Re: QtD 0.1 is out!
naryl Wrote: Eldar Insafutdinov Wrote: I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work. You mean the Revised BSD License I presume? It's a subject to discuss. I am not good at licenses.
Re: QtD 0.1 is out!
Don nos...@nospam.com wrote in message news:gn1saj$14u...@digitalmars.com... It feels to me like giving you a free car PROVIDED that you ensure that there is a coffee cup glued to the top of it at all times. I'd go for that ;-)
Re: QtD 0.1 is out!
Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do?
Re: QtD 0.1 is out!
On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb Thanks, that helped! I used it without any flags.
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb okay, second problem then - I need to be able to call extern (C) functions defined in D code from DLL. I tried to do getProcAddress(NULL, __some_D_func); but this doesn't work.
Re: QtD 0.1 is out!
On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb okay, second problem then - I need to be able to call extern (C) functions defined in D code from DLL. I tried to do getProcAddress(NULL, __some_D_func); but this doesn't work. I think you may have to write some code to explicitly register your D functions with the DLL. You could write a mini getDCodeProcAddress kind of thing in your D code. Then give a pointer to that function to the C code in the DLL at startup. Then C code uses getDCodeProcAddress from there. Maybe there's an easier way, but that's what I'd try. --bb
Re: QtD 0.1 is out!
On Thu, 12 Feb 2009 15:48:07 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb okay, second problem then - I need to be able to call extern (C) functions defined in D code from DLL. I tried to do getProcAddress(NULL, __some_D_func); but this doesn't work. I think you may have to write some code to explicitly register your D functions with the DLL. You could write a mini getDCodeProcAddress kind of thing in your D code. Then give a pointer to that function to the C code in the DLL at startup. Then C code uses getDCodeProcAddress from there. Maybe there's an easier way, but that's what I'd try. --bb This way won't really work because there are dozens of such a functions - that's for virtual dispatch. I have just solved it by declaring functions export extern (C) and adding _ prefix to function name when calling GetProcAddress. So technically there are no issues to make qtd working on windows! You are a genius! ;)
Re: QtD 0.1 is out!
Max Samukha Wrote: On Thu, 12 Feb 2009 15:48:07 -0500, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Bill Baxter Wrote: On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Can somebody help me with exporting functions from a DLL? I am defining functions in C++ like extern C __declspec(dllexport) void* __qtd_QObject_QObject_QObject(args) After compiling a DLL with MINGW and producing a lib file for it with implib I am trying to use them from D. In D I declare them as extern (C) void* __qtd_QObject_QObject_QObject(args); And then compile it and link it to the .lib file made by implib for that DLL, but optlink complains that symbol is undefined. I tried to use that Cfunction from C++ and it worked. What I can do? What's the implib command you're using? Often you need to use the /system flag. --bb okay, second problem then - I need to be able to call extern (C) functions defined in D code from DLL. I tried to do getProcAddress(NULL, __some_D_func); but this doesn't work. I think you may have to write some code to explicitly register your D functions with the DLL. You could write a mini getDCodeProcAddress kind of thing in your D code. Then give a pointer to that function to the C code in the DLL at startup. Then C code uses getDCodeProcAddress from there. Maybe there's an easier way, but that's what I'd try. --bb This way won't really work because there are dozens of such a functions - that's for virtual dispatch. I have just solved it by declaring functions export extern (C) and adding _ prefix to function name when calling GetProcAddress. So technically there are no issues to make qtd working on windows! You are a genius! ;) No, you are ;)
Re: QtD 0.1 is out!
Denis Koroskin Wrote: On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows. And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem..
Re: QtD 0.1 is out!
On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Denis Koroskin Wrote: On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows. And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem.. You could use mingw's GNU make with CC=dmc. But I dunno if dmc will compile Qt or not. I would think it would, though. --bb
Re: QtD 0.1 is out!
Bill Baxter Wrote: On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Denis Koroskin Wrote: On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows. And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem.. You could use mingw's GNU make with CC=dmc. But I dunno if dmc will compile Qt or not. I would think it would, though. --bb Actually I decided to make a dll. It is possible to do it and will be more robust solution. Qt is not tested to be compiled with dmc by trolltech(mingw, msvc and icc are guaranteed).
Re: QtD 0.1 is out!
Hello Eldar, Bill Baxter Wrote: On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: Denis Koroskin Wrote: On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows. And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem.. You could use mingw's GNU make with CC=dmc. But I dunno if dmc will compile Qt or not. I would think it would, though. --bb Actually I decided to make a dll. It is possible to do it and will be more robust solution. Qt is not tested to be compiled with dmc by trolltech(mingw, msvc and icc are guaranteed). A dll is probably your best option, if you can make it work with the C++ code(?). I would have thought you needed a C interface, though. dmc is rarely supported by the majority of open-source projects out there, so you end up having to fix a lot of makefiles and a lot of code. It is especially difficult getting C++ code working with such projects because many of these will use macro definitions to enable/disable certain vendor compiler features. Also you will run into C++ implementation differences that make dmc choke. On several occasions where I've tried to use dmc for the same reason, and I've come to the conclusion that dmc support is a whole project in itself. It's a huge waste of time if all you want is to interface with a library. I recommend the ddl route if you can make it work. Most others have done the same. Incindentally, if you are curious why projects like Derelict and other bindings (using dynamic loading) are so oft used in the D community, this is pretty much the reason. -JJR
Re: QtD 0.1 is out!
I recommend the ddl route if you can make it work. Sorry, not ddl... meant to say dll. :P
Re: QtD 0.1 is out!
ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now.
Re: QtD 0.1 is out!
On Wed, Feb 11, 2009 at 6:59 AM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. My usual approach is to use mingw to build a dll out of the needed functionality. If you can make the C++ part a DLL then a D program can use it just fine. --bb
Re: QtD 0.1 is out!
On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: ideage Wrote: Great stuff! Expect window's version! So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now. You can try building Qt with DMC. It works quite will in pair with DMD on Windows.
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
Daniel Keep wrote: Also, I apologise for the derailment. Oh I hear ya. Web development makes pacifistic people wanna kill. Including myself.
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
grauzone wrote: If you found a page where it is still active, can you please give me the url? http://www.digitalmars.com/d/archives/digitalmars/D/learn/Mixin_versus_c_preprocessor_11830.html Ah, I see. It's an older page, one that I didn't update. I suspect this is the offending piece of HTML: SCRIPT charset=utf-8 type=text/javascript src=http://ws.amazon.com/widgets/q?ServiceVersion=20070822MarketPlace=USID=V20070822/US/classicempire/8006/adfa749b-6f27-4cdf-a046-716a8fab7cab; /SCRIPT Yeah, that's it.
Re: QtD 0.1 is out!
grauzone Wrote: 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? Yes. But it is limited. No information, no dynamic invokation, different type of connections not implemented(but this theoretically is possible to do without moc)
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
Nick Sabalausky escribió: Daniel Keep daniel.keep.li...@gmail.com wrote in message news:gmg4av$dq...@digitalmars.com... Ary Borenszweig wrote: lol :) Yeah, well, for a directory listing they could have shown the full tree, but if it's too big then it's ugly, and browsing folder by folder (like dsource) is slow for me. The point is that instead of giving you a sub-optimal but functional alternative, they give you none. It's like not putting in wheelchair access ramps on the argument that they're inconvenient due to being a longer path than the stairs. You are right in that replacing href= with onclick= just for a link is stupid. Not just stupid; there's a whole circle of hell devoted to people who do that. They sit in endless thirst with water coolers everywhere. The catch is the taps have been replaced with low-resistance jobbies that require a special spanner to turn. Such spanners were never built. But... why Javascript hurts you that much? What did it do to you? Leaving aside Javascript the language and talking about JS as used in browsers, it's not the language itself. It's how it's used. It's the constant needless use of it that breaks the user experience. I think I enumerated all the big ones previously. Let's say you're moving house, and ask someone to help. They come over, and are really helpful. But every five minutes, they bitch-slap you and kick you between the legs. Then go back to being helpful. Eventually, you're going to throw them out no matter HOW helpful they is. Bad web developers have abused JS so much, so often and for so long, that I've decided it's less stressful to run with JS disabled. Don't even get me started on sites based entirely on Flash... Oh great, now you've gotten ME started on Flash... ;) There are a LOT of people (myself included), that will immediately leave a site, never to return, the moment they see that FlashBlocker box taking up 99% of the page. I can sum up all my feelings about Flash (and many, but not all, uses of JS) pretty simply: They are the 2000's version of animating GIFs and blink tags, except it's worse simply because most people don't seem to have actually learned anything from the history of animating GIFs and blink tags. Interesting side note: I've noticed that such flash-only pages and sites seem to be by far the most common among musicians and restaurant chains. Don't get me started on actual Flash development... (I have the oh-so-wonderful luck of being near the beginning of a large project that, due to client requirements, is built primarily on Flash and PHP. Whooo boy, am I having fun...(/sarcasm)) Oh, you are not near as lucky as me. Imagine a site built entirely in Silverlight. Whoo!!!
Re: QtD 0.1 is out!
Thank you! 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
Re: QtD 0.1 is out!
Great stuff! Expect window's version!
Re: QtD 0.1 is out!
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.
Re: QtD 0.1 is out!
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
Re: QtD 0.1 is out!
ideage Wrote: Great stuff! Expect window's version! I will probably do it in couple of weeks. Don't have time now :(
Re: QtD 0.1 is out!
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. Very cool! What versions of DMD/Tango are currently known to work with QtD? (ie, what are you developing against.) It'd be nifty to add a QtD profile to Sean Kerr's awesomely nifty sandboxing script. -- Chris Nicholson-Sauls
Re: QtD 0.1 is out!
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 :) )
Re: QtD 0.1 is out!
Daniel Keep escribió: 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... What? Why? A web like that without Javascript is awfuly slow and ugly... -- Daniel (Not angry at you, Eldar; angry at Google. They should know better :) )
Re: QtD 0.1 is out!
Daniel Keep daniel.keep.li...@gmail.com wrote in message news:gmfo1e$2kt...@digitalmars.com... 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... I'd be first in line for that even if I had to camp out all week. Plus, notice that you can't open one of the files in a new tab without it *also* opening in the same tab. That sort of garbage would never happen without JS. As for concerns about a web without JS being too slow: JS-heavy sites ARE absurdly slow. I never had a problem with lag on *basic text entry* on a 386 or even an Apple 2. But with Firefox it happens constantly. Pathetic.
Re: QtD 0.1 is out!
Nick Sabalausky a...@a.a wrote in message news:gmfr9m$2u5...@digitalmars.com... Plus, notice that you can't open one of the files in a new tab without it *also* opening in the same tab. Clarification: That problem seems to happen on Ctrl-Click, but not Right-Click-Open In New Tab.
Re: QtD 0.1 is out!
Daniel Keep daniel.keep.li...@gmail.com wrote in message news:gmfujj$2t...@digitalmars.com... Ary Borenszweig wrote: Daniel Keep escribió: 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... What? Why? A web like that without Javascript is awfuly slow and ugly... So... not having a scripting language would make pages run slower. ... I *really* hope you're joking. As for the ugly argument, that's bunk as well. The only two things you can't do without Javascript is to perform dynamic positioning and visibility. But you don't NEED those to make aesthetically pleasing pages. Just go look at CSS Zen Garden. *deep breath* tirade I have no problem with having scripting available for pages in general. But what DOES make me spew LIQUID HATE from every bodily orifice [1] is when they use Javascript to REPLACE FUNCTIONALITY THAT HTML ALREADY HAS. Like the sites where instead of using hyperlinks, they use Javascript in onclick events. Gee thanks, a**hole, you just broke tabs. Thanks for dictating how I'm allowed to view your site! Or the sites where they inject the content of the page like this: scriptdocument.write(THE PAGE CONTENT);/script Or pages where they have forms that go over perfectly ordinary HTTP POST and use perfectly ordinary form elements... but the submit button doesn't work BECAUSE IT REQUIRES F**KING SCRIPTING. This sort of bulls**t is inexcusable. It's like breaking someone's legs and saying but now you can use crutches; isn't that great?! No, you broke my legs you bastard! What's more, thanks to the plague of popup ads, ads that hang your browser for 5 seconds every time you mouse over the word synergy in an article, ads that show up in the same window but OVER the content, ads that play music or stream video when I'm on a QUOTA-LIMITED 'net connection, ads that start TALKING to you if your mouse goes anywhere near them or sites that just generally abuse the hell out of scripting, I'm amazed ANYONE browses the web with Javascript enabled by default. Frankly, if you build a site that utterly depends on Javascript to function [2], then you're an _idiot_. You want to use JS to make the site more usable? That's great! But you DO NOT break basic functionality to do it. EVER. If you can't figure out how, you're not qualified to be writing JS for web pages [3]. As someone who used to do web development: anyone, **ANYONE** who does this should be taken out back, shot, hung, drawn quartered then buried upside-down at a crossroads under a crucifix with a steak through the heart and a silver bullet in the head. Then burn and salt the earth just to make sure. /tirade Sorry about that, but MAN do I feel better. -- Daniel [1] ... to borrow a phrase from Ben Croshaw. [2] Obviously, this doesn't apply for sites that GENUINELY cannot function without Javascript. Stuff like Google Docs or a Javascript image editor; that stuff is fine because HTML can't do that. This is by far the best description/explanation of the evils of Javascript I have ever seen. It might sound a little extreme to some people, but speaking as another person who has done plenty of web development, there is absolutely no way to cover this topic *properly* without putting it in such terms. If the above rant is overly-*anything*, it's overly conciliatory. There's just no excuse for so many of the things that most web developers do. Now if we can only nudge Daniel to give the same treatment to Firefox 3... ;) BTW, Daniel, if you're on Firefox, you need to install the Adblock Plus addon and set it up with some of the subscriptions here: http://adblockplus.org/en/subscriptions I'm not exaggerating when I say that for a few months before I found that addon, using the web was so bad I was *very* close to abandoning use of the web entirely. (I have some other addon recommendations too, if you're interested.) In fact, that addon is the main reason I use Firefox as my primary browser even though I generally dislike Firefox. This addon still doesn't solve all of the problems with JS, but it at least changes to web from completely unusable garbage (and that's no exaggeration) to merely frequently irritating. Also, your footnote [3] seems to be missing...I'm on the edge of my seat here!!
Re: QtD 0.1 is out!
BCS wrote: Reply to Bill, On Fri, Feb 6, 2009 at 9:00 AM, Daniel Keep daniel.keep.li...@gmail.com wrote: You want to use JS to make the site more usable? That's great! But you DO NOT break basic functionality to do it. EVER. If you can't figure out how, you're not qualified to be writing JS for web pages [3]. [...] what I want to known is what happened to that last footnote! I believe I was going to make a comment to the effect that it's fine to make websites like this for the purposes of learning. I decided that I was probably going a bit far in attempting to clarify myself. -- Daniel
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
Ary Borenszweig wrote: lol :) Yeah, well, for a directory listing they could have shown the full tree, but if it's too big then it's ugly, and browsing folder by folder (like dsource) is slow for me. The point is that instead of giving you a sub-optimal but functional alternative, they give you none. It's like not putting in wheelchair access ramps on the argument that they're inconvenient due to being a longer path than the stairs. You are right in that replacing href= with onclick= just for a link is stupid. Not just stupid; there's a whole circle of hell devoted to people who do that. They sit in endless thirst with water coolers everywhere. The catch is the taps have been replaced with low-resistance jobbies that require a special spanner to turn. Such spanners were never built. But... why Javascript hurts you that much? What did it do to you? Leaving aside Javascript the language and talking about JS as used in browsers, it's not the language itself. It's how it's used. It's the constant needless use of it that breaks the user experience. I think I enumerated all the big ones previously. Let's say you're moving house, and ask someone to help. They come over, and are really helpful. But every five minutes, they bitch-slap you and kick you between the legs. Then go back to being helpful. Eventually, you're going to throw them out no matter HOW helpful they is. Bad web developers have abused JS so much, so often and for so long, that I've decided it's less stressful to run with JS disabled. Don't even get me started on sites based entirely on Flash... -- Daniel
Re: QtD 0.1 is out!
Bill Baxter wbax...@gmail.com wrote in message news:mailman.658.1233882921.22690.digitalmars-d-annou...@puremagic.com... http://adblockplus.org/en/subscriptions I'm not exaggerating when I say that for a few months before I found that addon, using the web was so bad I was *very* close to abandoning use of the web entirely. What kind of sites do you go that are so bad? I find things a little annoying without FlashBlock, and I have Firefox's default popup blocking on, but with those two things, I don't see much of anything all *that* annoying in my day-to-day web use. So I'm wondering if it has to do with the sites you frequent or something? Or is it just your threshold for tolerating an ad or two is so much lower than mine? FlashBlock is another one of my essential addons :) Let me put it this way: I don't have any sort of documented reading disability (ex, I've always done well on reading comprehension tests). But dispite that, I find it nearly impossible to read anything more than a single trivial sentence whenever there's anything moving, blinking, spinning, a slideshow, etc anywhere near the text (or when there's a voice reading it to me). It's not just annoying, it's a genuine distraction that my mind is simply unable to block out. Plus, as far as I'm concerned, there shouldn't be any moving, spinning, pulsating, animating crap to be blocked out of my mind in the first place.
Re: QtD 0.1 is out!
Nick Sabalausky wrote: Bill Baxter wbax...@gmail.com wrote in message news:mailman.658.1233882921.22690.digitalmars-d-annou...@puremagic.com... http://adblockplus.org/en/subscriptions I'm not exaggerating when I say that for a few months before I found that addon, using the web was so bad I was *very* close to abandoning use of the web entirely. What kind of sites do you go that are so bad? I find things a little annoying without FlashBlock, and I have Firefox's default popup blocking on, but with those two things, I don't see much of anything all *that* annoying in my day-to-day web use. So I'm wondering if it has to do with the sites you frequent or something? Or is it just your threshold for tolerating an ad or two is so much lower than mine? FlashBlock is another one of my essential addons :) Let me put it this way: I don't have any sort of documented reading disability (ex, I've always done well on reading comprehension tests). But dispite that, I find it nearly impossible to read anything more than a single trivial sentence whenever there's anything moving, blinking, spinning, a slideshow, etc anywhere near the text (or when there's a voice reading it to me). It's not just annoying, it's a genuine distraction that my mind is simply unable to block out. Plus, as far as I'm concerned, there shouldn't be any moving, spinning, pulsating, animating crap to be blocked out of my mind in the first place. I run AdBlock, NoScript, FlashBlock and Nuke Anything Enchanced. And if I DO see an ad get through all that, I add the company to my mental people I will never buy from list. I'm an advertiser's worst nightmare. -- Daniel
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
Daniel Keep daniel.keep.li...@gmail.com wrote in message news:gmg4av$dq...@digitalmars.com... Ary Borenszweig wrote: lol :) Yeah, well, for a directory listing they could have shown the full tree, but if it's too big then it's ugly, and browsing folder by folder (like dsource) is slow for me. The point is that instead of giving you a sub-optimal but functional alternative, they give you none. It's like not putting in wheelchair access ramps on the argument that they're inconvenient due to being a longer path than the stairs. You are right in that replacing href= with onclick= just for a link is stupid. Not just stupid; there's a whole circle of hell devoted to people who do that. They sit in endless thirst with water coolers everywhere. The catch is the taps have been replaced with low-resistance jobbies that require a special spanner to turn. Such spanners were never built. But... why Javascript hurts you that much? What did it do to you? Leaving aside Javascript the language and talking about JS as used in browsers, it's not the language itself. It's how it's used. It's the constant needless use of it that breaks the user experience. I think I enumerated all the big ones previously. Let's say you're moving house, and ask someone to help. They come over, and are really helpful. But every five minutes, they bitch-slap you and kick you between the legs. Then go back to being helpful. Eventually, you're going to throw them out no matter HOW helpful they is. Bad web developers have abused JS so much, so often and for so long, that I've decided it's less stressful to run with JS disabled. Don't even get me started on sites based entirely on Flash... Oh great, now you've gotten ME started on Flash... ;) There are a LOT of people (myself included), that will immediately leave a site, never to return, the moment they see that FlashBlocker box taking up 99% of the page. I can sum up all my feelings about Flash (and many, but not all, uses of JS) pretty simply: They are the 2000's version of animating GIFs and blink tags, except it's worse simply because most people don't seem to have actually learned anything from the history of animating GIFs and blink tags. Interesting side note: I've noticed that such flash-only pages and sites seem to be by far the most common among musicians and restaurant chains. Don't get me started on actual Flash development... (I have the oh-so-wonderful luck of being near the beginning of a large project that, due to client requirements, is built primarily on Flash and PHP. Whooo boy, am I having fun...(/sarcasm))
Re: QtD 0.1 is out!
Hello Bill, http://adblockplus.org/en/subscriptions I'm not exaggerating when I say that for a few months before I found that addon, using the web was so bad I was *very* close to abandoning use of the web entirely. What kind of sites do you go that are so bad? I find things a little annoying without FlashBlock, and I have Firefox's default popup blocking on, but with those two things, I don't see much of anything all *that* annoying in my day-to-day web use. So I'm wondering if it has to do with the sites you frequent or something? Or is it just your threshold for tolerating an ad or two is so much lower than mine? --bb It's not always about the class of sites anymore. Although naturally, there will be a higher incident of problems among certain types of sites. The problems are starting to prevalent among many types of sites since these locations, commercial or otherwise, are pushing a lot more than they use to. Many elements (like flash) are not necessarily visible, but still gather permanent information on you, and it doesn't seem to matter if you had your cookies disabled or not. I use noscript with firefox (which also allows control of Java and Flash). I completely agree that the use of JavaScript is pretty evil these days. Even worse is that websites are taking advantage of so many people that are rather ignorant of how to protect themselves. I have found some sites that are quite surfable without javascript: I'm very impressed when I see this because it says volumes about their good manners and respect for the user. I must admit that I also get greatly irritated when I come across websites that are inoperable without javascript. I often will refuse to use them... unless I really must. Contrary to popular opinion, javascript does not appear to be a dire necessity for a fast, usable website (though, I also admit there are certain good applications for it). Javascript is one of the worst potential security breeches today /especially/ because of all the websites that force you to keep it enabled. Unfortunately, most people have become so dependent on it that they can't think of giving it up just to have more privacy and security. Yet disabling JavaScript remains one of the most highly recommended ways to eliminate a whole spectrum of attacks that regularly can sneek through all your anti-virus and anti-malware software. And the attacks can come from websites that normally would be harmless because sometimes they get injected (I don't know how) with evil Javascript that is just waiting to be run in your browser. Flash is also a secret horror. The funny thing is that the blocking of cookies has long been controllable in most browsers, but little is said about flash local shared objects that can accomplish the same sort of tracking in a much more hidden medium. Even worse is that there is much less stricture on these objects (like expiry dates and storage size). There is a way to limit these LSO's but few people seem to know or think about this being necessary. A simple google search on Flash cookies gives a fair amount on interesting information on this. Incidentally Google is another one to keep your eye on; and while I don't want to sound alarmist, I think Google will eventually could turn out to be one of the greatest security/privacy concerns on the web over the next few years. They have managed to spread their influence everywhere by getting people excited on various ideas, and it's amazing to see that almost every website out there is linked to Google in sort of way or use a free Google feature (google analytics for one). All these free services are concerns. It seems Google is very clever... a little too clever for my liking. Overall, I think the web is a mess... a dangerous mess, and it's getting worse as fast as people are becoming ignorant: the gap expands even faster in the relative sense. I'm guessing the security and privacy risk it presents to the public will only get worse as we eat up the freebies, for which most of us have developed a taste from the bountiful supply of the information age. There's a general apathy that has grown along side it all. -JJR PS. I've found a few good ways to view both outgoing and incoming internet communications. Any sort of port logging is both interesting and educational. A couple good pieces of software to monitor these things are PeerGuardian2 (not only useful for p2p ... just generally useful to see incoming/outgoing traffic) and PortReporter (a Microsoft tool). Both allow you to see what kind of probes occur over time, including what your computer is doing to communicate with the outside world, perhaps even when you don't intend it to. :P
Re: OT: Scripting on websites [Was: Re: QtD 0.1 is out!]
Nick Sabalausky wrote: Interesting side note: I've noticed that such flash-only pages and sites seem to be by far the most common among musicians and restaurant chains. Yup; I *hate* looking up tour dates. Don't get me started on actual Flash development... (I have the oh-so-wonderful luck of being near the beginning of a large project that, due to client requirements, is built primarily on Flash and PHP. Whooo boy, am I having fun...(/sarcasm)) lol, enjoy!
Re: QtD 0.1 is out!
Nick Sabalausky wrote: Daniel Keepdaniel.keep.li...@gmail.com wrote in message news:gmfujj$2t...@digitalmars.com... Ary Borenszweig wrote: Daniel Keep escribió: 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... What? Why? A web like that without Javascript is awfuly slow and ugly... So... not having a scripting language would make pages run slower. ... I *really* hope you're joking. As for the ugly argument, that's bunk as well. The only two things you can't do without Javascript is to perform dynamic positioning and visibility. But you don't NEED those to make aesthetically pleasing pages. Just go look at CSS Zen Garden. *deep breath* tirade I have no problem with having scripting available for pages in general. But what DOES make me spew LIQUID HATE from every bodily orifice [1] is when they use Javascript to REPLACE FUNCTIONALITY THAT HTML ALREADY HAS. Like the sites where instead of using hyperlinks, they use Javascript in onclick events. Gee thanks, a**hole, you just broke tabs. Thanks for dictating how I'm allowed to view your site! Or the sites where they inject the content of the page like this: scriptdocument.write(THE PAGE CONTENT);/script Or pages where they have forms that go over perfectly ordinary HTTP POST and use perfectly ordinary form elements... but the submit button doesn't work BECAUSE IT REQUIRES F**KING SCRIPTING. This sort of bulls**t is inexcusable. It's like breaking someone's legs and saying but now you can use crutches; isn't that great?! No, you broke my legs you bastard! What's more, thanks to the plague of popup ads, ads that hang your browser for 5 seconds every time you mouse over the word synergy in an article, ads that show up in the same window but OVER the content, ads that play music or stream video when I'm on a QUOTA-LIMITED 'net connection, ads that start TALKING to you if your mouse goes anywhere near them or sites that just generally abuse the hell out of scripting, I'm amazed ANYONE browses the web with Javascript enabled by default. Frankly, if you build a site that utterly depends on Javascript to function [2], then you're an _idiot_. You want to use JS to make the site more usable? That's great! But you DO NOT break basic functionality to do it. EVER. If you can't figure out how, you're not qualified to be writing JS for web pages [3]. As someone who used to do web development: anyone, **ANYONE** who does this should be taken out back, shot, hung, drawn quartered then buried upside-down at a crossroads under a crucifix with a steak through the heart and a silver bullet in the head. Then burn and salt the earth just to make sure. /tirade Sorry about that, but MAN do I feel better. -- Daniel [1] ... to borrow a phrase from Ben Croshaw. [2] Obviously, this doesn't apply for sites that GENUINELY cannot function without Javascript. Stuff like Google Docs or a Javascript image editor; that stuff is fine because HTML can't do that. This is by far the best description/explanation of the evils of Javascript I have ever seen. It might sound a little extreme to some people, but speaking as another person who has done plenty of web development, there is absolutely no way to cover this topic *properly* without putting it in such terms. If the above rant is overly-*anything*, it's overly conciliatory. There's just no excuse for so many of the things that most web developers do. Now if we can only nudge Daniel to give the same treatment to Firefox 3... ;) BTW, Daniel, if you're on Firefox, you need to install the Adblock Plus addon and set it up with some of the subscriptions here: http://adblockplus.org/en/subscriptions I'm not exaggerating when I say that for a few months before I found that addon, using the web was so bad I was *very* close to abandoning use of the web entirely. (I have some other addon recommendations too, if you're interested.) In fact, that addon is the main reason I use Firefox as my primary browser even though I generally dislike Firefox. This addon still doesn't solve all of the problems with JS, but it at least changes to web from completely unusable garbage (and that's no exaggeration) to merely frequently irritating. You must frequent some fantastically horrible websites. I use the 'net quite frequently, and I don't experience anywhere near enough consternation to even consider finding a popup blocker.
Re: QtD 0.1 is out!
Hello Chris, Nick Sabalausky wrote: Daniel Keepdaniel.keep.li...@gmail.com wrote in message news:gmfujj$2t...@digitalmars.com... Ary Borenszweig wrote: Daniel Keep escribió: 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... What? Why? A web like that without Javascript is awfuly slow and ugly... So... not having a scripting language would make pages run slower. ... I *really* hope you're joking. As for the ugly argument, that's bunk as well. The only two things you can't do without Javascript is to perform dynamic positioning and visibility. But you don't NEED those to make aesthetically pleasing pages. Just go look at CSS Zen Garden. *deep breath* tirade I have no problem with having scripting available for pages in general. But what DOES make me spew LIQUID HATE from every bodily orifice [1] is when they use Javascript to REPLACE FUNCTIONALITY THAT HTML ALREADY HAS. Like the sites where instead of using hyperlinks, they use Javascript in onclick events. Gee thanks, a**hole, you just broke tabs. Thanks for dictating how I'm allowed to view your site! Or the sites where they inject the content of the page like this: scriptdocument.write(THE PAGE CONTENT);/script Or pages where they have forms that go over perfectly ordinary HTTP POST and use perfectly ordinary form elements... but the submit button doesn't work BECAUSE IT REQUIRES F**KING SCRIPTING. This sort of bulls**t is inexcusable. It's like breaking someone's legs and saying but now you can use crutches; isn't that great?! No, you broke my legs you bastard! What's more, thanks to the plague of popup ads, ads that hang your browser for 5 seconds every time you mouse over the word synergy in an article, ads that show up in the same window but OVER the content, ads that play music or stream video when I'm on a QUOTA-LIMITED 'net connection, ads that start TALKING to you if your mouse goes anywhere near them or sites that just generally abuse the hell out of scripting, I'm amazed ANYONE browses the web with Javascript enabled by default. Frankly, if you build a site that utterly depends on Javascript to function [2], then you're an _idiot_. You want to use JS to make the site more usable? That's great! But you DO NOT break basic functionality to do it. EVER. If you can't figure out how, you're not qualified to be writing JS for web pages [3]. As someone who used to do web development: anyone, **ANYONE** who does this should be taken out back, shot, hung, drawn quartered then buried upside-down at a crossroads under a crucifix with a steak through the heart and a silver bullet in the head. Then burn and salt the earth just to make sure. /tirade Sorry about that, but MAN do I feel better. -- Daniel [1] ... to borrow a phrase from Ben Croshaw. [2] Obviously, this doesn't apply for sites that GENUINELY cannot function without Javascript. Stuff like Google Docs or a Javascript image editor; that stuff is fine because HTML can't do that. This is by far the best description/explanation of the evils of Javascript I have ever seen. It might sound a little extreme to some people, but speaking as another person who has done plenty of web development, there is absolutely no way to cover this topic *properly* without putting it in such terms. If the above rant is overly-*anything*, it's overly conciliatory. There's just no excuse for so many of the things that most web developers do. Now if we can only nudge Daniel to give the same treatment to Firefox 3... ;) BTW, Daniel, if you're on Firefox, you need to install the Adblock Plus addon and set it up with some of the subscriptions here: http://adblockplus.org/en/subscriptions I'm not exaggerating when I say that for a few months before I found that addon, using the web was so bad I was *very* close to abandoning use of the web entirely. (I have some other addon recommendations too, if you're interested.) In fact, that addon is the main reason I use Firefox as my primary browser even though I generally dislike Firefox. This addon still doesn't solve all of the problems with JS, but it at least changes to web from completely unusable garbage (and that's no exaggeration) to merely frequently irritating. You must frequent some fantastically horrible websites. I use the 'net quite frequently, and I don't experience anywhere near enough consternation to even consider finding a popup blocker. Yeah, I don't go to that many websites beyong a usual few. Firefox's built-in popup blocker has been sufficient for me (and it usually tells me when it has blocked a popup). It's actually been a long time since I've worried too much about popups. I /do/ remember the day, though, when popups were a problem, and it was annoying. My beef
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.
