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

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?

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>

Daniel Keep wrote:
> Also, I apologise for the derailment.

Oh I hear ya. Web development makes pacifistic people wanna kill. Including myself.

grauzone wrote:
>> If you found a page where it is still active, can you please give me the url?
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/learn/Mixin_versus_c_preprocessor_11830.html 

Ah, I see. It's an older page, one that I didn't update.

> I suspect this is the offending piece of HTML:
> 
> <SCRIPT charset="utf-8" type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&MarketPlace=US&ID=V20070822/US/classicempire/8006/adfa749b-6f27-4cdf-a046-716a8fab7cab"> </SCRIPT>

Yeah, that's it.

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!

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

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

Fawzi Mohamed wrote:
> On 2009-02-27 21:49:58 +0100, Fawzi Mohamed <fmohamed@mac.com> said:
>
>> On 2009-02-27 21:10:29 +0100, Walter Bright
>> <newshound1@digitalmars.com> said:
>>
>>> Eldar Insafutdinov wrote:
>>>> Now we have to make a manual init function called from class
>>>> constructors. I understand that allowing static consructors with
>>>> cyclic imports will make order of their execution undefined, but this
>>>> is acceptable and actually semantically doesn't break the idea of
>>>> cyclic imports. Otherwise in my opinion this behavior is
>>>> inconsistent..
>>>
>>> One of the goals of D is to eliminate undefined behavior wherever
>>> possible. In C++, the undefined order of static construction was a
>>> source of many porting problems. I think it's better in the long run
>>> to have a defined order, even if it means having to reorganize the
>>> code a bit.
>>
>> I fully agree,
> *avoiding*
>> circular dependencies between modules is in general a good practice:
>> a circular dependency it means that you have tight coupling, in in
>> that case it is normally better to have everything in the same module
>> to have a better control on it.
>> Sometime one has cases in which circular dependencies arise, two ways
>> to get rid of them are for example:
>>
>> 1) define and interface, the circular dependency is in the interfaces
>> that are described in the same module, the two (or more) modules
>> include the interfaces, and are not directly dependent on each other
>> (only through the interfaces)
>>
>> 2) use templates, the circular dependencies are on a template
>> parameter. The circular dependencies arise only upon instantiation
>
>

I agree with the above but there is still a small issue here:
A module is a single file and when you have several large classes that are tightly coupled you can get a very big file with thousands of lines. what if i want to put each class in its own file?
besides, the notion of a module is somewhat redundant - it's functionally a static struct.

this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly.

On Sat, Feb 28, 2009 at 11:05 AM, Yigal Chripun <yigal100@gmail.com> wrote:
>
> I agree with the above but there is still a small issue here:
> A module is a single file and when you have several large classes that are
> tightly coupled you can get a very big file with thousands of lines. what if
> i want to put each class in its own file?
> besides, the notion of a module is somewhat redundant - it's functionally a
> static struct.
>
> this is related to D's compilation model which is copied from C/C++ and it seems to me that this model is outdated. C#'s model of assemblies and metadata seems more capable. for instance there's no need for header files, that info is stored in the metadata of the assembly.
>

Preciiiisely.  I've been toying with the concept of a compiler which doesn't actually emit object files until it has to link its code into some form of executable.  Instead it produces these sort of platform-independent internal representation files, which can contain all the metadata and symbol information needed.  They can be as small as a single module or as large as an entire multi-level package.  It sounds a lot like the model C# has adopted.