Re: COM/OLE advanced questions
You'd better read some more authorative source since my experience is very limited on that matter, but here is some quick notes On Thursday, 2 November 2017 at 14:22:56 UTC, Guillaume Piolat wrote: Question 1. Is it mandatory to inherit from core.sys.windows.unknwn.IUnknown, or just having an interface named "IUnknown" validate it for being a COM interface? If yes, then how am I supposed to use COM interfaces in other OSes? core.sys.windows.unknwn.IUnknown is defined under version(Windows). I wonder what the exact compiler hook is. You can't(or maybe you can but that is not a true COM). COM is Windows tech. It is backed up by OLE or whatever server it is. My guess it will work fine when derive from any extern(Windows) interface(that's right, not class) that has base 3 methods(AddRef, Release, QueryInterface) It is also tied to a Windows registry, since to be able to create COM objects using CoCreateInstance its class factory has to be registered with class id (CLSID), then IIRC, for example in C# creating a COM object instance(using new) makes corresponding lookup by GUID to retrieve CLSID and CoCreateInstance calls that factory to make an object. But you don't have to use COM mechanincs on your COM enabled classes inside your code. Now there can be a problem, say for example you want to make a COM class in D for external usage, most likely you will have to make interface first, then derive a class for actual implementation, because class will add stuff to vtable and break order. (just a guess) Question 2. If this fails, may I emulate COM vtable layout with extern(C++) class? I wonder what the exact differences are anyway between extern(C++) and the special IUnknown. I don't know the exact internals mechanics, but yes, not sure if extern(C++) will work though. COM can be used from C, and so COM methods is basically a C function that takes object as first argument, so on C++ side it is flavored to make a vtable and respective method calls(or vice versa, depending how the specific class implemented). (like I said, find some better read on this) Also since it can be implemented in C, and that requires manually making COM vtable in there(IIRC with an array), you can just do the same in D. Question 3. It seems I can inherit both from A D object and a COM interface. What will be the choosen layout? like I said in Q2, if your goal is to make COM class accessible by other languages then make interface derived from IUnknown(or any other COM interface you like) and fill in the methods, but implement them in derived from that interface class. (again, just a guess, because of vtable shifting) and don't forget, on Windows you also must register a class factory (see IClassFactory.CreateInstance) to be able to create objects from other COM clients.
Re: simple DIP1000 test fails?
On Thursday, November 02, 2017 18:54:15 Steven Schveighoffer via Digitalmars-d-learn wrote: > On 11/2/17 6:10 PM, Jonathan M Davis wrote: > > I haven't read DIP 25 > > recently, but I assume that the return on id is equivalent to marking > > the > > this parameter with return, in which case, the compiler knows where the > > returned reference came from. So, returning by ref shouldn't be a > > problem. The problem is simply taking the address, since the S is a > > temporary, and that's already caught by @safe even without compiling > > with -dip25. > Right, the whole point of 'return' is to tell the compiler that the > 'this' parameter is getting returned. IMO, this shouldn't even work on > rvalues. It's not even the taking of the address, it's the fact that the > address of the result outlives the rvalue. The compiler should be able > to tell that if I call id with an rvalue, the resulting reference can't > escape the expression. > > So it's somewhat of a cross between dip1000 and dip25, but obviously > neither flags it. I would think that it would be fine if you simply called a member function on the rvalue. You couldn't pass the rvalue to any function accepting ref, so the ref return would largely be pointless, but allowing a member function to be called on the ref returned rvalue would mean that you could still use the member function that returned by ref with an rvalue, whereas otherwise, you'd be forced to assign it to a variable, which wouldn't be the end of the world, but it would lose out on some flexibility that technically should work just fine. But I don't think that there's any question that what's allowed with that ref return needs to be more restricted, since doing something like taking its address or passing it to a free function that accepts by ref would be really bad, and if disallowing calling ref return functions on rvalues was the most reasonable way to stop that, then it wouldn't be the end of the world. - Jonathan M Davis
Re: simple DIP1000 test fails?
On 11/2/17 6:10 PM, Jonathan M Davis wrote:
Except that IIRC, DIP 25 only applies to @safe code.
I think the original implementation only applied to @safe code, but it
seems to have an effect on @system code as well:
Stevens-MacBook-Pro:testd steves$ cat testdip25.d
ref int foo(ref int s)
{
return s;
}
void main()
{
int i;
int *p = (i);
}
Stevens-MacBook-Pro:testd steves$ dmd testdip25.d
Stevens-MacBook-Pro:testd steves$ dmd -dip25 testdip25.d
testdip25.d(3): Error: returning s escapes a reference to parameter s,
perhaps annotate with return
I haven't read DIP 25
recently, but I assume that the return on id is equivalent to marking the
this parameter with return, in which case, the compiler knows where the
returned reference came from. So, returning by ref shouldn't be a problem.
The problem is simply taking the address, since the S is a temporary, and
that's already caught by @safe even without compiling with -dip25.
Right, the whole point of 'return' is to tell the compiler that the
'this' parameter is getting returned. IMO, this shouldn't even work on
rvalues. It's not even the taking of the address, it's the fact that the
address of the result outlives the rvalue. The compiler should be able
to tell that if I call id with an rvalue, the resulting reference can't
escape the expression.
So it's somewhat of a cross between dip1000 and dip25, but obviously
neither flags it.
-Steve
Re: simple DIP1000 test fails?
On Thursday, November 02, 2017 16:39:43 Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 11/2/17 4:07 PM, Jonathan M Davis wrote:
> > On Thursday, November 02, 2017 14:03:52 Jonathan M Davis via
> > Digitalmars-d->
> > learn wrote:
> >> On Thursday, November 02, 2017 19:53:36 Q. Schroll via
> >> Digitalmars-d-learn>>
> >> wrote:
> >>> struct S { ref S id() return { return this; } }
> >>> void main() { S* p = ().id(); }
> >>
> >> Well, if you make them @safe, it won't compile whether -dip1000 is used
> >> or not. At the moment, I don't recall whether -dip1000's effects are
> >> supposed to be limited to @safe code or not though. If they are, then
> >> I don't think that there's a bug, but if they aren't, then it looks
> >> like there is.
> >
> > Though actually, scope isn't used anywhere here, and IIRC, -dip1000 only
> > comes into affect when scope is used. So, I don't think that -dip1000
> > really applies here. But I'm not as well-versed in the ins and outs of
> > DIP 1000 as I should be, so I could be wrong.
>
> The issue here is that rvalues bind to the `this` reference. I think
> this is actually dip25, and it's definitely a bug. Whatever kicks in
> when dip25 is enabled (tried -dip25 and -dip1000 switch, and it still
> compiles) is not understanding the lifetime of the rvalue in order to
> properly apply it to the resulting ref.
Except that IIRC, DIP 25 only applies to @safe code. I haven't read DIP 25
recently, but I assume that the return on id is equivalent to marking the
this parameter with return, in which case, the compiler knows where the
returned reference came from. So, returning by ref shouldn't be a problem.
The problem is simply taking the address, since the S is a temporary, and
that's already caught by @safe even without compiling with -dip25.
So, unless I'm remembering wrong, and -dip25 actually applies to @system
code as well, then I don't think that this is a bug in -dip25.
- Jonathan M Davis
Re: Issues with Vibe.d Dynamic HTML with JSON
On Thursday, 2 November 2017 at 18:51:09 UTC, bauss wrote:
On Thursday, 2 November 2017 at 18:48:10 UTC, bauss wrote:
Before you did:
render!("index.dt", title, major_categories);
Have you tried to check the contents of "major_categories"
making sure it's all there. Just to figure out whether the
problem is in the view rendering or the json parsing.
I checked, it seemed as though the JSON was all there.
Also alternatively have you tried "vibe.data.json"?
http://vibed.org/api/vibe.data.json/
I just converted my code to use vibe's library instead of the
phobos Json implementation.
Now I'm not getting any output whatsoever. I'm wondering if it's
an issue with Diet not wanting to do that many levels of nested
iterations...
Also the vibe.data.json.Json.toString() method does something
awful to that Json string. After I fix that I might be able to
get more debugging info...
Here's my Diet. I basically just pass a Json object to render!:
doctype html
html
head
title #{json["title"].get!string}
body
- import std.stdio : writeln;
- import vibe.data.json : Json;
h1 #{json["title"].get!string}
- foreach (major; json["major_categories"].get!(Json[])) {
- string major_category_name =
major["title"].get!string;
- major_category_name.writeln();
h2 #{major_category_name}
- foreach (minor; major["categories"].get!(Json[])) {
h4 #{minor["title"].get!string}
p
- foreach (item; minor["links"].get!(Json[]))
{
a(href="#{item[\"url\"].get!string}")
#{item["label"].get!string}
br
- }
- }
- }
Re: Line numbers in backtraces (2017)
On Thursday, 2 November 2017 at 19:05:46 UTC, Tobias Pankrath
wrote:
Including Phobos? Your posted backtrace looks to me like
templates instantiated within Phobos, so I think you'd need
Phobos with debug symbols for those lines.
---
int main(string[] argv)
{
return argv[1].length > 0;
}
---
~ [i] % rdmd -g -debug test.d
core.exception.RangeError@test.d(3): Range violation
No difference when I compile with 'dmd -g -debug' and run in
manually.
That Error is thrown from within druntime. If you want to see
line numbers for backtraces locations within druntime, you need
to compile druntime with debug symbols.
Also `-debug` only changes conditional compilation behaviour[1].
[1] https://dlang.org/spec/version.html#DebugCondition
Re: simple DIP1000 test fails?
On 11/2/17 4:07 PM, Jonathan M Davis wrote:
On Thursday, November 02, 2017 14:03:52 Jonathan M Davis via Digitalmars-d-
learn wrote:
On Thursday, November 02, 2017 19:53:36 Q. Schroll via Digitalmars-d-learn
wrote:
struct S { ref S id() return { return this; } }
void main() { S* p = ().id(); }
Well, if you make them @safe, it won't compile whether -dip1000 is used or
not. At the moment, I don't recall whether -dip1000's effects are
supposed to be limited to @safe code or not though. If they are, then I
don't think that there's a bug, but if they aren't, then it looks like
there is.
Though actually, scope isn't used anywhere here, and IIRC, -dip1000 only
comes into affect when scope is used. So, I don't think that -dip1000 really
applies here. But I'm not as well-versed in the ins and outs of DIP 1000 as
I should be, so I could be wrong.
The issue here is that rvalues bind to the `this` reference. I think
this is actually dip25, and it's definitely a bug. Whatever kicks in
when dip25 is enabled (tried -dip25 and -dip1000 switch, and it still
compiles) is not understanding the lifetime of the rvalue in order to
properly apply it to the resulting ref.
-Steve
Re: simple DIP1000 test fails?
On Thursday, November 02, 2017 14:03:52 Jonathan M Davis via Digitalmars-d-
learn wrote:
> On Thursday, November 02, 2017 19:53:36 Q. Schroll via Digitalmars-d-learn
> wrote:
> > struct S { ref S id() return { return this; } }
> > void main() { S* p = ().id(); }
>
> Well, if you make them @safe, it won't compile whether -dip1000 is used or
> not. At the moment, I don't recall whether -dip1000's effects are
> supposed to be limited to @safe code or not though. If they are, then I
> don't think that there's a bug, but if they aren't, then it looks like
> there is.
Though actually, scope isn't used anywhere here, and IIRC, -dip1000 only
comes into affect when scope is used. So, I don't think that -dip1000 really
applies here. But I'm not as well-versed in the ins and outs of DIP 1000 as
I should be, so I could be wrong.
- Jonathan M Davis
Re: simple DIP1000 test fails?
On Thursday, November 02, 2017 19:53:36 Q. Schroll via Digitalmars-d-learn
wrote:
> struct S { ref S id() return { return this; } }
> void main() { S* p = ().id(); }
Well, if you make them @safe, it won't compile whether -dip1000 is used or
not. At the moment, I don't recall whether -dip1000's effects are supposed
to be limited to @safe code or not though. If they are, then I don't think
that there's a bug, but if they aren't, then it looks like there is.
- Jonathan M Davis
simple DIP1000 test fails?
I've tried to get into the changes by DIP1000 and discovered this:
struct S { ref S id() return { return this; } }
void main() { S* p = ().id(); }
Should it really compile? (rdmd -dip1000 .\test_return_ref.d)
Re: Line numbers in backtraces (2017)
Including Phobos? Your posted backtrace looks to me like
templates instantiated within Phobos, so I think you'd need
Phobos with debug symbols for those lines.
---
int main(string[] argv)
{
return argv[1].length > 0;
}
---
~ [i] % rdmd -g -debug test.d
core.exception.RangeError@test.d(3): Range violation
No difference when I compile with 'dmd -g -debug' and run in
manually.
Re: Issues with Vibe.d Dynamic HTML with JSON
On Thursday, 2 November 2017 at 18:48:10 UTC, bauss wrote:
On Thursday, 2 November 2017 at 16:23:55 UTC, SamwiseFilmore
wrote:
On Thursday, 2 November 2017 at 08:40:28 UTC, bauss wrote:
[...]
No, the html does come in, and the whole content of the
rendered page is sent to the browser. The page has closing
head and body tags.
[...]
I'll play with that. Would there be any reason for my data to
get randomly truncated?
Before you did:
render!("index.dt", title, major_categories);
Have you tried to check the contents of "major_categories"
making sure it's all there. Just to figure out whether the
problem is in the view rendering or the json parsing.
Also alternatively have you tried "vibe.data.json"?
http://vibed.org/api/vibe.data.json/
Re: Issues with Vibe.d Dynamic HTML with JSON
On Thursday, 2 November 2017 at 16:23:55 UTC, SamwiseFilmore
wrote:
On Thursday, 2 November 2017 at 08:40:28 UTC, bauss wrote:
Do you get a response back with rendered html or does the
connection get dropped?
No, the html does come in, and the whole content of the
rendered page is sent to the browser. The page has closing head
and body tags.
Have you tried to cut down the amount of data and see if it
will render it all? That should eliminate whether it's the
amount of data or what.
I'll play with that. Would there be any reason for my data to
get randomly truncated?
Before you did:
render!("index.dt", title, major_categories);
Have you tried to check the contents of "major_categories" making
sure it's all there. Just to figure out whether the problem is in
the view rendering or the json parsing.
Re: COM/OLE advanced questions
AFAIK you can only use COM from windows anyway. OK I have been using them from linux but only with WINE help. On Thu, Nov 2, 2017 at 3:22 PM, Guillaume Piolat via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > I wonder if anyone has used COM in dlang extensively. > > Context: I must use COM FFI interfacing on systems that aren't > necessarily Windows. It is essential that the layout of interfaces and > classes are the same than in equivalent C++ objects. > > > Question 1. Is it mandatory to inherit from core.sys.windows.unknwn.IUnknown, > or just having an interface named "IUnknown" validate it for being a COM > interface? > >If yes, then how am I supposed to use COM interfaces in other OSes? > core.sys.windows.unknwn.IUnknown is defined under version(Windows). > >I wonder what the exact compiler hook is. > > > Question 2. If this fails, may I emulate COM vtable layout with > extern(C++) class? I wonder what the exact differences are anyway between > extern(C++) and the special IUnknown. > > > Question 3. It seems I can inherit both from A D object and a COM > interface. What will be the choosen layout? >
Re: Issues with Vibe.d Dynamic HTML with JSON
On Thursday, 2 November 2017 at 08:40:28 UTC, bauss wrote: Do you get a response back with rendered html or does the connection get dropped? No, the html does come in, and the whole content of the rendered page is sent to the browser. The page has closing head and body tags. Have you tried to cut down the amount of data and see if it will render it all? That should eliminate whether it's the amount of data or what. I'll play with that. Would there be any reason for my data to get randomly truncated?
Re: Any book recommendation for writing a compiler?
On Wednesday, 1 November 2017 at 20:53:44 UTC, Dr. Assembly wrote: Hey guys, if I were to get into dmd's source code to play a little bit (just for fun, no commercial use at all), which books/resources do you recommend to start out? You don't need to read books to write a compiler, a bit of theory from "here or there" will be enough, particularly if you start from scratch, there's almost no chance that you ever touch the more edgy things (something like theory of types maybe ). A few ones written in D (sorted by URL length): - https://github.com/dlang/dmd - https://github.com/BBasile/yatol - https://github.com/higgsjs/Higgs - https://github.com/VoltLang/Volta - https://github.com/beast-lang/beast-dragon Otherwise a subreddit that's not been quoted yet: - https://www.reddit.com/r/ProgrammingLanguages/ and their homepage listing a few projects from people who have started "the journey": http://www.proglangdesign.net/
COM/OLE advanced questions
I wonder if anyone has used COM in dlang extensively. Context: I must use COM FFI interfacing on systems that aren't necessarily Windows. It is essential that the layout of interfaces and classes are the same than in equivalent C++ objects. Question 1. Is it mandatory to inherit from core.sys.windows.unknwn.IUnknown, or just having an interface named "IUnknown" validate it for being a COM interface? If yes, then how am I supposed to use COM interfaces in other OSes? core.sys.windows.unknwn.IUnknown is defined under version(Windows). I wonder what the exact compiler hook is. Question 2. If this fails, may I emulate COM vtable layout with extern(C++) class? I wonder what the exact differences are anyway between extern(C++) and the special IUnknown. Question 3. It seems I can inherit both from A D object and a COM interface. What will be the choosen layout?
Re: Issue with sc.ini within XMake build infrastructure
On Thursday, 2 November 2017 at 13:01:05 UTC, rikki cattermole wrote: On 02/11/2017 1:56 PM, Andre Pany wrote: On Thursday, 2 November 2017 at 12:21:50 UTC, rikki cattermole wrote: Override the shipped sc.ini file with your own. Simple and effective solution. What I just found out, by calling the batch file "vcvars64.bat" from the visual studio folder it seems everything is already pre configured (LIB environment variable needed for the linker contains paths to lib\x64, ucrt\x64 and um\x64) and also the path environment variable has already the right value in first place: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64; I have to ship an almost empty sc.ini. Everything else is set by the vcvars64.bat file. It would be great if the default sc.ini would anticipate the usage of vcvars*.bat. Just call the batch and everything works out of the box. Kind regards André Guess what all "just works" with the installer? :p unfortunately I cannot use the installer. But I found an interesting comment in sc.ini: ; Add the library subdirectories of all VC and Windows SDK versions so things ; just work for users using dmd from the VS 64-bit Command Prompt According to these comment I would assume, after calling "vcvars64.bat" everything should work. Maybe it worked in the past and it is a bug. My tests: - I changed the line "LINKCMD=%VCINSTALLDIR%\bin\link.exe" to "LINKCMD=link.exe" Unfortunately this optlink linker is also called link.exe *argh* - After renaming the optlink linker to optlink.exe the microsoft linker does not find a lib, which is definitely in the LIB environment path. I think there are some bugs to solve but it definitely makes the usage of Visual Studio linker much more comfortable in build infrastructure. I will create an issue for this. Kind regards André
Re: Issue with sc.ini within XMake build infrastructure
On 02/11/2017 1:56 PM, Andre Pany wrote: On Thursday, 2 November 2017 at 12:21:50 UTC, rikki cattermole wrote: Override the shipped sc.ini file with your own. Simple and effective solution. What I just found out, by calling the batch file "vcvars64.bat" from the visual studio folder it seems everything is already pre configured (LIB environment variable needed for the linker contains paths to lib\x64, ucrt\x64 and um\x64) and also the path environment variable has already the right value in first place: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64; I have to ship an almost empty sc.ini. Everything else is set by the vcvars64.bat file. It would be great if the default sc.ini would anticipate the usage of vcvars*.bat. Just call the batch and everything works out of the box. Kind regards André Guess what all "just works" with the installer? :p
Re: Issue with sc.ini within XMake build infrastructure
On Thursday, 2 November 2017 at 12:21:50 UTC, rikki cattermole wrote: Override the shipped sc.ini file with your own. Simple and effective solution. What I just found out, by calling the batch file "vcvars64.bat" from the visual studio folder it seems everything is already pre configured (LIB environment variable needed for the linker contains paths to lib\x64, ucrt\x64 and um\x64) and also the path environment variable has already the right value in first place: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64; I have to ship an almost empty sc.ini. Everything else is set by the vcvars64.bat file. It would be great if the default sc.ini would anticipate the usage of vcvars*.bat. Just call the batch and everything works out of the box. Kind regards André
Re: Issue with sc.ini within XMake build infrastructure
On 02/11/2017 12:42 PM, Andre Pany wrote: Hi, I have a windows slave on which the dmd archive is extracted and dub is executed using build scripts. The windows slave has Visual Studio 2017 installed. I would like to switch from OMF to COFF executables to also allow 64 bit compilations. My issue is, there is no way to install DMD using the executable setup but only extracting the DMD archive. Also editing the sc.ini (by a build script) I dislike. I tried to begin with an easy example. I set the environment variables: SET UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10 SET UCRTVersion=10.0.16299.0 SET VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503 SET LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe SET LIB=%LIB%;"%VCINSTALLDIR%\lib\x64" SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64" SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64" and after that I called dmd to compile a test application using the -m64 switch. From the error I can see, that my LINKCMD environment variable is overwritten by the sc.ini line: LINKCMD=%VCINSTALLDIR%\bin\link.exe Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\link.exe', check PATH. How can I solve this issue? Kind regards André Override the shipped sc.ini file with your own. Simple and effective solution.
Issue with sc.ini within XMake build infrastructure
Hi, I have a windows slave on which the dmd archive is extracted and dub is executed using build scripts. The windows slave has Visual Studio 2017 installed. I would like to switch from OMF to COFF executables to also allow 64 bit compilations. My issue is, there is no way to install DMD using the executable setup but only extracting the DMD archive. Also editing the sc.ini (by a build script) I dislike. I tried to begin with an easy example. I set the environment variables: SET UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10 SET UCRTVersion=10.0.16299.0 SET VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503 SET LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe SET LIB=%LIB%;"%VCINSTALLDIR%\lib\x64" SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64" SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64" and after that I called dmd to compile a test application using the -m64 switch. From the error I can see, that my LINKCMD environment variable is overwritten by the sc.ini line: LINKCMD=%VCINSTALLDIR%\bin\link.exe Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\link.exe', check PATH. How can I solve this issue? Kind regards André
Re: Any book recommendation for writing a compiler?
On Thursday, 2 November 2017 at 03:55:27 UTC, Michael V. Franklin wrote: On Wednesday, 1 November 2017 at 20:53:44 UTC, Dr. Assembly wrote: Hey guys, if I were to get into dmd's source code to play a little bit (just for fun, no commercial use at all), which books/resources do you recommend to start out? I found this to be quite helpful: http://llvm.org/docs/tutorial/ Specifically the Kaleidoscope tutorial. Mike If you are interested in using LLVM my little project might be helpful: https://github.com/igor84/summus
Re: Issues with Vibe.d Dynamic HTML with JSON
On Thursday, 2 November 2017 at 04:00:10 UTC, SamwiseFilmore wrote: I've got a serialized JSON structure that looks something like this: [...] Do you get a response back with rendered html or does the connection get dropped? Have you tried to cut down the amount of data and see if it will render it all? That should eliminate whether it's the amount of data or what.
