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



use a DLL anyway for commercial use.


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


 

 use a DLL anyway for commercial use.
 

 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



 use a DLL anyway for commercial use.


 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:


 use a DLL anyway for commercial use.
 

 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:


 use a DLL anyway for commercial use.


 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:


 use a DLL anyway for commercial use.


 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:








se

 a DLL anyway for commercial use.


 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 

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

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

 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



I also think that source code organization should be orthogonal to the 
organization of the deployment executables (assemblies in .net)


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

 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)



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.


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 

 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++ 

 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 

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



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



 
 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