www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - QtD 0.1 is out!

reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 04 2009
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.

For those who don't know: http://code.google.com/p/qtd/
Feb 04 2009
parent reply "ideage" <ideage gmail.com> writes:
Great stuff!

Expect window's version! 
Feb 05 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
ideage Wrote:

 Great stuff!
 
 Expect window's version! 
 
 

I will probably do it in couple of weeks. Don't have time now :(
Feb 05 2009
prev sibling next sibling parent reply David Ferenczi <raggae ferenczi.net> writes:
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.

Feb 05 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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
Feb 05 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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 :) )
Feb 05 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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 :) )

Feb 05 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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:
 <script>document.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.
Feb 05 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Also, I apologise for the derailment.

Back on topic for a moment, I've never worked with Qt before, but going
over some of the examples it shows definite promise.  It certainly looks
easier to use than other toolkits I've worked with in the past.

Again, sorry for getting off-topic, and do keep up the good work.  :)

  -- Daniel
Feb 05 2009
parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Daniel Keep wrote:
 Also, I apologise for the derailment.

Oh I hear ya. Web development makes pacifistic people wanna kill. Including myself.
Feb 07 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Feb 6, 2009 at 9:00 AM, Daniel Keep <daniel.keep.lists gmail.com> wrote:

 </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.

There's something really humorous about a guy going on a rambling, fired-up, emotional tirade for a page and a half, but concluding it with proper footnotes. :-) --bb
Feb 05 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Bill,

 On Fri, Feb 6, 2009 at 9:00 AM, Daniel Keep
 <daniel.keep.lists 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!
 </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.
 

There's something really humorous about a guy going on a rambling, fired-up, emotional tirade for a page and a half, but concluding it with proper footnotes. :-) --bb

Feb 05 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
BCS wrote:
 Reply to Bill,
 
 On Fri, Feb 6, 2009 at 9:00 AM, Daniel Keep
 <daniel.keep.lists 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
Feb 05 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gmfujj$2t5$1 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:
 <script>document.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!!
Feb 05 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
 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
Feb 05 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.658.1233882921.22690.digitalmars-d-announce 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.
Feb 05 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Nick Sabalausky wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.658.1233882921.22690.digitalmars-d-announce 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
Feb 05 2009
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gmg4oj$dqp$2 digitalmars.com...
 Nick Sabalausky wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.658.1233882921.22690.digitalmars-d-announce 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.

I use QuickJava instead of NoScript. I find it handy to be able to toggle JS on/off with just a single click. I used to keep JS off by default and only turn it on when I really needed it, but sites requiring JS became more and more common to the point that I ended up reluctantly just keeping JS on by default, and only turning it off when something obnoxious is going on. Not an action I'm proud of, but it keeps me sane. My other bare-minimum essentials, in addition to Adblock Plus and FlashBlock, are Winestripe, Tab Mix Plus, and DisableBackspaceNavigation. I also make heavy use of Repagination, DownThemAll (I'm a packrat), BatchDownload, DownloadHelper, Download Statusbar (a little ugly, but much more handy than the default download window) and FasterFox (useful to see just how absurdly slow page-loading often is. I'm on a good broadband connection, and I frequently find sites that take 40-50 seconds to load a single page whenever JS is enabled (that's a good example of how JS slows the web down instead of speeding it up)).
Feb 05 2009
prev sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Nick Sabalausky wrote:
 
 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. 
 
 

Whoa. At some point I realized that I was at peace with the web because my eye balls would automatically repel from all of the pulsating/spinny/blinky crap on the sides of web pages. So apparently my mind works a bit differently than yours. My brain must have, at some point, grown entire subnetworks of neurons dedicated to spam blocking. I have come to consciously realize this as well, and become incredibly thankful to it at the same time. Nick, you have my sympathies. Unfortunately for me, conceptual distractions are the bane of my existence. Really, I should be doing homework right now. But I'm not. I'm doing this instead.
Feb 05 2009
prev sibling parent John Reimer <terminal.node gmail.com> writes:
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
Feb 05 2009
prev sibling parent reply Chris R Miller <lordsauronthegreat gmail.com> writes:
Nick Sabalausky wrote:
 "Daniel Keep"<daniel.keep.lists gmail.com>  wrote in message
 news:gmfujj$2t5$1 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:
 <script>document.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.
Feb 05 2009
next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Chris,

 Nick Sabalausky wrote:
 
 "Daniel Keep"<daniel.keep.lists gmail.com>  wrote in message
 news:gmfujj$2t5$1 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:
 <script>document.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 is mostly with JS and Flash which noscript handles quite well. -JJR
Feb 05 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Chris R Miller" <lordsauronthegreat gmail.com> wrote in message 
news:gmgeq2$11jp$1 digitalmars.com...
 Nick Sabalausky wrote:
 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.

Adblock Plus blocks any type of ad, not just popups. To be honest, I would have no problem with web ads if they were just simple static images like from back before popups. It's just all of the visual-movement, slow-JS, potential for malware, etc. that I can't/won't tolerate.
Feb 05 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Daniel Keep escribió:
 
 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>

(...)
 
 </tirade>
 
 Sorry about that, but MAN do I feel better.

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. You are right in that replacing href="" with onclick="" just for a link is stupid. But... why Javascript hurts you that much? What did it do to you?
Feb 05 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Feb 05 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gmg4av$dqp$1 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))
Feb 05 2009
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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!
Feb 05 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky escribió:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gmg4av$dqp$1 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. Whoooooo!!!
Feb 06 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Ary Borenszweig wrote:
 Oh, you are not near as lucky as me. Imagine a site built entirely in 
 Silverlight. Whoooooo!!!

I can -- it looks like about:blank.
Feb 06 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 07 Feb 2009 02:36:54 +0300, Christopher Wright <dhasenan gmail.com>
wrote:

 Ary Borenszweig wrote:
 Oh, you are not near as lucky as me. Imagine a site built entirely in  
 Silverlight. Whoooooo!!!

I can -- it looks like about:blank.

It is also built entirely in JavaScript. But wait!.. How can it be built entirely in Silvermoon if it is built entirely in JavaScript? o_O
Feb 06 2009
prev sibling parent reply grauzone <none example.net> writes:
 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.
Feb 05 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:gmgjou$1af5$1 digitalmars.com...
 But... why Javascript hurts you that much? What did it do to you?


 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?)

Yes, yes, yes, exactly! A couple more examples of API docs that are barely-usable (ie, painful sluggishness, lack of offline viewing, and general bugginess) thanks to AJAX: MSDN Library and Adobe LiveDocs.
 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.

Yes, yes, yes, exactly! DVD menus do it too, and the blatant lack of thought that goes into such a design always irritates me. "I don't want to [watch | listen to] some cute little [transition | movie quote | film clip], I just want to [watch the movie | select a scene | setup audio options | view extras]." Most people, like myself, who have spent time in game programming (particularly old-school style games) learn very quickly that interactive interfaces need to have response times of no more than about 100ms max (preferably less) and transition times of no more than about 250ms (preferably less) for the user to really feel "in control". That's *not* much time, and far less time than many modern interface designers (games or otherwise) are comfortable restricting themselves to these days. I think part of the problem is that artists and graphic designers are usually hired for these jobs instead of actual interactive interface designers (because when most managers think "user interface" they just think of the visual side, and sometimes audio too, but they don't know that there are also temporal and usability concerns).
 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.

I have a certain viewpoint on that: AIUI, The strict definition of "technology" is the application of science to improve the quality of life. As such, there are many things that people consider to be "technologies" that I insist aren't technologies because they only satisfy the "application of science" part and not the "improve the quality of life" part. (A related pet peeve I have when dealing with laymen: "Technology" does not necessarily imply "electronics". Heck, even indoor plumbing is a technology...and one of my personal favorites ;) )
Feb 05 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 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.

I had some email discussions with Amazon about the miserable speed of the Amazon cloud widget. The idea of the cloud widget is great, it's supposed to look at the contents of the page and produce links to Amazon products, like books, that are related. So I really wanted this to work. But Amazon tech support insisted that it was not slow, it was merely pining for the fjords (ok, I added that last bit <g>). I was seeing load times that averaged around 30 seconds. In the face of that, I removed the widget a few weeks ago, after telling tech support I'd add it back in once they fixed the speed problems. If you found a page where it is still active, can you please give me the url?
Feb 06 2009
parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 grauzone wrote:
 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.

I had some email discussions with Amazon about the miserable speed of the Amazon cloud widget. The idea of the cloud widget is great, it's supposed to look at the contents of the page and produce links to Amazon products, like books, that are related. So I really wanted this to work. But Amazon tech support insisted that it was not slow, it was merely pining for the fjords (ok, I added that last bit <g>). I was seeing load times that averaged around 30 seconds.

Not sure what you're saying, but it was eating up my CPU even some minutes after the page was loaded.
 In the face of that, I removed the widget a few weeks ago, after telling 
 tech support I'd add it back in once they fixed the speed problems.
 
 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 I suspect this is the offending piece of HTML: <SCRIPT charset="utf-8" type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&MarketPlace=US&ID=V20070822/US/classicempire/8006/adfa749b-6f27-4cdf a046-716a8fab7cab"> </SCRIPT>
Feb 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
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_pre rocessor_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=20070822&MarketPlace=US&ID=V20070822/US/classicempire/8006/adfa749b-6f27-4cdf
a046-716a8fab7cab"> 
 </SCRIPT>

Yeah, that's it.
Feb 07 2009
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Ary,

 What? Why?
 
 A web like that without Javascript is awfuly slow and ugly...
 

without javascript, the page should show the full directory tree (or n levels down). they could get real cute and have that anyway and just have the JS hide it.
Feb 05 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gmfo1e$2ktp$1 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.
Feb 05 2009
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gmfr9m$2u54$1 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".
Feb 05 2009
prev sibling parent grauzone <none example.net> writes:
Daniel Keep wrote:
 
 Eldar Insafutdinov wrote:
 David Ferenczi Wrote:

 I'm glad to see this release and the progress of qtd!

 Coudl you please provide a link to the tutrial? Many thanks!

 Eldar Insafutdinov wrote:

 It didn't take very long after previous post to make a first
 implementation of signals and slots(thanks to great people from #d) which
 means that you can actually start doing something useful. 0.1 is probably
 most suitable tag for this release. Again - see tutorials for how to use
 signals.


tutorials are in trunk/examples http://code.google.com/p/qtd/source/browse/#svn/trunk/examples

"No files in this directory." Well that sucks. Oh well, I... hey, wait a second... *unblocks javascript* "No files in this directory, but there ARE subdirectories!" Sometimes, I really wish there was a way to electrocute people for making their sites break without Javascript... -- Daniel (Not angry at you, Eldar; angry at Google. They should know better :) )

Finally somehow who shares my pain. You have my sympathy. Especially Google is really bad with this. Not only are they pushing AJAX. They completely fail to make their sites useful without JS. Did you ever try to browse Youtube with JavaScript disabled? It's really fun to see, for what things they thought you _must_ have JS enabled. (My solution to this is not to browse Youtube at all.)
Feb 05 2009
prev sibling parent David Ferenczi <raggae ferenczi.net> writes:
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

Feb 06 2009
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Feb 05 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Chris Nicholson-Sauls Wrote:

 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

It's dmd v1.036 and tango-trunk dated November 25. But QtD is not on the bleeding edge of both compiler and tango, so I think tango 1.037 will be enough, so as compiler. I should specify dependency on tango on main page.
Feb 05 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
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?
Feb 05 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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)
Feb 06 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 10 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Feb 11, 2009 at 6:59 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 ideage Wrote:

 Great stuff!

 Expect window's version!

So after some time trying to build qtd windows packages I realized that t=

here 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 t= old 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 suppo= rt 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
Feb 10 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Wed, Feb 11, 2009 at 6:59 AM, Eldar Insafutdinov
 <e.insafutdinov 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

Thanks, but could you please clarify something for me: as well as D part, C++ part is calling extern "C" functions defined in D part of the binding. will this work with dll? And also currently it doesn't use dynamic loading - it's just plain extern (C) function definitions on both sides, is this an issue?
Feb 10 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
<e.insafutdinov 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.
Feb 10 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Denis Koroskin Wrote:

 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
<e.insafutdinov 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..
Feb 11 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 Denis Koroskin Wrote:

 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
<e.insafutdinov 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
Feb 11 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Denis Koroskin Wrote:

 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
<e.insafutdinov 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).
Feb 11 2009
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Eldar,

 Bill Baxter Wrote:
 
 On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 
 Denis Koroskin Wrote:
 
 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
 <e.insafutdinov 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
Feb 11 2009
next sibling parent John Reimer <terminal.node gmail.com> writes:
 I recommend the ddl route if you can make it work.  

Sorry, not "ddl"... meant to say dll. :P
Feb 11 2009
prev sibling parent reply Don <nospam nospam.com> writes:
John Reimer wrote:
 Hello Eldar,
 
 Bill Baxter Wrote:

 On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:

 Denis Koroskin Wrote:

 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 12 2009
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Don Wrote:

 John Reimer wrote:
 Hello Eldar,
 
 Bill Baxter Wrote:

 On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:

 Denis Koroskin Wrote:

 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 12 2009
next sibling parent Don <nospam nospam.com> writes:
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.insafutdinov gmail.com> wrote:

 Denis Koroskin Wrote:

 On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
 <e.insafutdinov 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!
Feb 12 2009
prev sibling parent naryl <cy ngs.ru> writes:
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?
Feb 12 2009
prev sibling parent reply naryl <cy ngs.ru> writes:
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. :)
Feb 12 2009
next sibling parent reply Don <nospam nospam.com> writes:
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.
Feb 12 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:gn1saj$14uo$1 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 ;-)
Feb 12 2009
prev sibling parent Arnold S. <governator california.gov> writes:
Don Wrote:

 naryl wrote:
 Don Wrote:
 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.

Awesome. It'll be law by next Tuesday. Thanks for the idea. -AS
Feb 12 2009
prev sibling parent reply renoX <renosky free.fr> writes:
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.. Too bad as it creates a lot of different LGPL-like license. That said, I know for sure that the LGPLv2 prevents static linking I don't know about the LGPLv3 though. BR, renoX
Feb 16 2009
parent Daniel de Kok <me danieldk.org> writes:
On Tue, Feb 17, 2009 at 7:06 AM, renoX <renosky free.fr> wrote:
 naryl a =E9crit :
 Don Wrote:
 Well, since Qt is going to use the lunatic# LGPL license, you have to u=



se
 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 th=


at
 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 chang=

e
 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
Feb 17 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 12 2009
parent reply Mike Parker <aldacron gmail.com> writes:
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
Feb 12 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 13 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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?
Feb 12 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
<e.insafutdinov 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
Feb 12 2009
next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 12 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 12 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
 <e.insafutdinov 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
Feb 12 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 12 Feb 2009 22:22:41 +0300, Eldar Insafutdinov  
<e.insafutdinov 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.
Feb 13 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
 <e.insafutdinov 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!
Feb 12 2009
next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Thu, 12 Feb 2009 15:48:07 -0500, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:

Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
 <e.insafutdinov 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! ;)
Feb 12 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Max Samukha Wrote:

 On Thu, 12 Feb 2009 15:48:07 -0500, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 
Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 5:00 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Fri, Feb 13, 2009 at 4:22 AM, Eldar Insafutdinov
 <e.insafutdinov 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 ;)
Feb 12 2009
prev sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 14 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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..
Feb 15 2009
next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
<e.insafutdinov 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.
Feb 15 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
<samukha voliacable.com.removethis> wrote:
 On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
 <e.insafutdinov 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
Feb 15 2009
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter gmail.com>
wrote:

On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
<samukha voliacable.com.removethis> wrote:
 On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 15 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Max Samukha Wrote:

 On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter gmail.com>
 wrote:
 
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
<samukha voliacable.com.removethis> wrote:
 On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 15 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Feb 16, 2009 at 10:32 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:

 The reason why is this file is big is in this bug http://d.puremagic.com/=

issues/show_bug.cgi?id=3D282 And I don't thing that placing enums outside t= he 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.co= re.Qt module you can't access it like Qt.A - which means that we have to ke= ep 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 ;-)
Feb 15 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Eldar Insafutdinov Wrote:

 Max Samukha Wrote:
 
 On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter gmail.com>
 wrote:
 
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
<samukha voliacable.com.removethis> wrote:
 On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
 <e.insafutdinov 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.

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.
Feb 15 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 The reason why is this file is big is in this bug http://d.puremagic.com=


/issues/show_bug.cgi?id=3D282 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.c= ore.Qt module you can't access it like Qt.A - which means that we have to k= eep 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.
Feb 15 2009
next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Jarrett Billingsley Wrote:

 On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov
 <e.insafutdinov 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.

It's the way Qt is. I can't change the API.
Feb 16 2009
prev sibling parent reply grauzone <none example.net> writes:
Jarrett Billingsley wrote:
 On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 16 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Feb 16, 2009 at 7:10 AM, grauzone <none example.net> wrote:
 Jarrett Billingsley wrote:
 On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov
 <e.insafutdinov 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.

Because that's redefining the problem rather than solving it? Circular dependencies are not always a sign of bad design. Shoving everything into one module sure is.
Feb 16 2009
prev sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Sun, 15 Feb 2009 21:27:35 -0500, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:

Eldar Insafutdinov Wrote:

 Max Samukha Wrote:
 
 On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter gmail.com>
 wrote:
 
On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha
<samukha voliacable.com.removethis> wrote:
 On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 16 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
<e.insafutdinov 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
Feb 15 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 15 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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
Feb 15 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 15 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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
Feb 15 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 15 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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
Feb 15 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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?
Feb 15 2009
parent reply Don <nospam nospam.com> writes:
Eldar Insafutdinov wrote:
 Bill Baxter Wrote:
 
 On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 16 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Don Wrote:

 Eldar Insafutdinov wrote:
 Bill Baxter Wrote:
 
 On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:
 Bill Baxter Wrote:

 On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
 <e.insafutdinov 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.

Ok, so I splitted all big files, circular imports now don't cause troubles. But optlink still crashes. Something else I can try?
Feb 16 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 16 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Feb 16, 2009 at 8:26 PM, Walter Bright
<newshound1 digitalmars.com> 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 don't know if you realize just how unbelievably unhelpful that advice is for the typical user.
Feb 16 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Mon, Feb 16, 2009 at 8:26 PM, Walter Bright
 <newshound1 digitalmars.com> 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 don't know if you realize just how unbelievably unhelpful that advice is for the typical user.

You aren't the typical user <g>. If the obj file is not well-formed, it's a compiler bug, and hence presumably much easier for me to fix.
Feb 16 2009
prev sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 16 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 21 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Feb 22, 2009 at 5:27 AM, Eldar Insafutdinov
<e.insafutdinov 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
Feb 21 2009
prev sibling next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:

 On Sun, Feb 22, 2009 at 5:27 AM, Eldar Insafutdinov
 <e.insafutdinov 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.
Feb 21 2009
prev sibling next sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
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!
Feb 21 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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?
Feb 21 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sun, Feb 22, 2009 at 7:45 AM, Eldar Insafutdinov
<e.insafutdinov 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
Feb 21 2009
parent reply Moritz Warning <moritzwarning web.de> writes:
On Sun, 22 Feb 2009 08:04:12 +0900, Bill Baxter wrote:

 On Sun, Feb 22, 2009 at 7:45 AM, Eldar Insafutdinov
 <e.insafutdinov 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?
Feb 21 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sun, Feb 22, 2009 at 10:16 AM, Moritz Warning <moritzwarning 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.insafutdinov 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
Feb 21 2009
next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Sun, 22 Feb 2009 10:26:04 +0900, Bill Baxter wrote:

 On Sun, Feb 22, 2009 at 10:16 AM, Moritz Warning <moritzwarning 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.insafutdinov 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

Thanks. I've added some info.
Feb 21 2009
prev sibling parent grauzone <none example.net> writes:
Bill Baxter wrote:
 On Sun, Feb 22, 2009 at 10:16 AM, Moritz Warning <moritzwarning 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.insafutdinov 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

So the bug will likely be fixed in the next version of dmd? I'm really glad to hear this!
Feb 21 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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?
Feb 27 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov
<e.insafutdinov 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.
Feb 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov 
 <e.insafutdinov 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.
Feb 27 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Walter Bright Wrote:

 Jarrett Billingsley wrote:
 On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov 
 <e.insafutdinov 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..
Feb 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 27 2009
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 27 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 27, 2009 at 5:07 PM, Walter Bright
<newshound1 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.
Feb 27 2009
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-02-27 21:10:29 +0100, Walter Bright <newshound1 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
Feb 27 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-02-27 21:49:58 +0100, Fawzi Mohamed <fmohamed mac.com> said:

 On 2009-02-27 21:10:29 +0100, Walter Bright <newshound1 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

Feb 27 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Fawzi Mohamed wrote:
 On 2009-02-27 21:49:58 +0100, Fawzi Mohamed <fmohamed mac.com> said:

 On 2009-02-27 21:10:29 +0100, Walter Bright
 <newshound1 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.
Feb 28 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun <yigal100 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.

Preciiiisely. 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.
Feb 28 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Jarrett Billingsley wrote:
 On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun<yigal100 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.

Preciiiisely. 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.
Feb 28 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Yigal Chripun wrote:
 On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun<yigal100 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
Feb 28 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 28 2009
parent reply Don <nospam nospam.com> writes:
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.
Mar 01 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Mar 1, 2009 at 10:16 AM, Don <nospam 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?
Mar 01 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:
 On Sun, Mar 1, 2009 at 10:16 AM, Don <nospam 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.
Mar 01 2009
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Feb 28 2009
next sibling parent reply grauzone <none example.net> writes:
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.
Feb 28 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Feb 28 2009
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.

Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug.
Feb 28 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 28 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 3:05 PM, Walter Bright
<newshound1 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!
Feb 28 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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). Andrei
Feb 28 2009
parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 28 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 5:30 PM, Derek Parnell <derek psych.ward> wrote:

 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" =A0;-)

Encapsulosity.
Feb 28 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Feb 28 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Feb 28 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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?
Mar 01 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
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)".
Mar 01 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 01 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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...
Mar 01 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 01 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Feb 28 2009
next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-02-28 14:54:26 +0100, Christopher Wright <dhasenan 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 :)
Feb 28 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Christopher Wright wrote:
 This opens you up to certain bugs,

Yes, the bug where module A depends on module B being initialized first, yet B imports A. With this patch, it may or may not work correctly, as order of initialization for cyclic imports will be unpredictable.
 but they should be relatively rare.

But nasty, as they tend to show up when porting or updating the compiler or build system, long after the original programmer left. Furthermore, these bugs may go undetected at QA time if nobody put a test for proper initialization in the test suite. Java is a very portable language, not because of the VM, but because it tries to eliminate all implementation and undefined behavior. It hasn't been 100% successful at that, but this facet of Java has, in my opinion, been a big factor in the wide adoption of Java. In contrast, only experienced C and C++ programmers are able to write code that ports reliably. Experience at having been burned by implementation and undefined language behavior. This is no longer acceptable in a language.
 I've tried it, and it appears to work.

That's the problem with undefined behavior :-(, it only appears to work. It is not guaranteed to work.
Feb 28 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Feb 28 2009
parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Feb 28 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
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.

I read on http://code.google.com/p/qtd/ the following: "QtD requires tango. Those who use phobos should try tangobos or modify qtd(that should not be very difficult)." I bet quite some of the non-Tango users ignore QtD because they don't want to install Tango just for one thing. If you can find a Phobos user who has done this "not very diffcult" QtD modification, he might write a short description. And a link to that could be on the page, next to the sentence. Even better would of course be to make QtD work with both already.
Mar 06 2009
next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Georg Wrede Wrote:

 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.

I read on http://code.google.com/p/qtd/ the following: "QtD requires tango. Those who use phobos should try tangobos or modify qtd(that should not be very difficult)." I bet quite some of the non-Tango users ignore QtD because they don't want to install Tango just for one thing. If you can find a Phobos user who has done this "not very diffcult" QtD modification, he might write a short description. And a link to that could be on the page, next to the sentence. Even better would of course be to make QtD work with both already.

of course once there is somebody to do this job, it will appear in repos. Moreover there will be starting a job to port it to D2. Most probably there won't be D1+phobos support. I don't use phobos myself and the trend is that some projects I like use tango. DWT is one of them and it also uses tango. So the main concentration will be on D1-tango and D2-phobos I guess.
Mar 06 2009
prev sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 06 Mar 2009 18:34:19 +0200, Georg Wrede <georg.wrede iki.fi>
wrote:

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.

I read on http://code.google.com/p/qtd/ the following: "QtD requires tango. Those who use phobos should try tangobos or modify qtd(that should not be very difficult)." I bet quite some of the non-Tango users ignore QtD because they don't want to install Tango just for one thing. If you can find a Phobos user who has done this "not very diffcult" QtD modification, he might write a short description. And a link to that could be on the page, next to the sentence. Even better would of course be to make QtD work with both already.

I'm planning to make it work with D2 sooner or later. No plans for D1+phobos.
Mar 07 2009