Disqus - Latest Comments for _Alan_

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

_Alan_ — Thu, 12 Nov 2009 10:00:26 -0000

To alleviate means "to make less severe" in this case.

Re: Mono Tools for Visual Studio - Miguel de Icaza

_Alan_ — Wed, 11 Nov 2009 07:14:02 -0000

Or, more importantly, the developer of said application accidentally does something stupid like hardcoding a path which doesn't exist on other operating systems. Or they don't take into account the fact their app will break on a case sensitive file system. Or they attempt to store data in the same folder as their executable, but that folder is locked off in different operating systems.

These are things which mono can never compensate [0] for and that's why you need to test under the actual target operating system.

[0] Mono has an IO mapping layer which can handle some path issues when porting apps from windows-> other operating systems, but it has a performance hit (faking a case insensitive filesystem isn't free!) and should only really be used if the actual app can't be fixed.

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

_Alan_ — Mon, 09 Nov 2009 16:11:38 -0000

I'm sorry that issues intrinsic to garbage collected languages disappoint you.

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

_Alan_ — Mon, 09 Nov 2009 14:21:14 -0000

Generally, less than the cost of a regular stream. When a standard memorystream resizes you must copy the entire old buffer to the new buffer. With a chunked memory stream you have to copy exactly zero bytes when resizing, you just add or remove a chunk from the list. Reading/writing shouldn't have noticably more overhead unless your typical usage is reading a handful of bytes at a time.

As with all things, benchmark if you want exact numbers ;)

Re: Stream.CopyStream - Miguel de Icaza

_Alan_ — Wed, 24 Sep 2008 21:51:02 -0000

How could System.IO.Stream ever implement CopyStream? It'd be a nightmare to implement!

The problem is that the Stream in question could be *anything*, i.e. a NetworkStream. By reading data from this stream (in order to make a copy) you will render the initial stream unusable because you've already read the data out, and you cannot rewind it. What you end up with is a single usable version of the stream instead of two.

If you want to be able to 'Copy' a stream, you have to do it manually. You need to read all the data from the initial stream as a byte[], then instantiate all the MemoryStreams you want from this byte[].

Suppose you wanted to implement Stream.CopyStream, you could create a class like

public class StreamSplitter : Stream
{
public StreamSplitter (Stream initialStream)
{
// Do stuff
}

public Stream GetCopy()
{
// Do stuff
}
}

Internally the StreamSplitter will read from the initial stream and store the data in a byte[]. GetCopy will then return a MemoryStream type class based on this byte[]. This class would have the ability to tell the StreamSplitter to get more data from the initial stream and make it available to all the copies which have been created.

The problem is that any copy can initiate this request for more data at any time. This is a pain in the ass for thread synchronisation with regards to the initial stream. Then you have more threading problems when you try making this new data available to the existing copies. All i can say is that there's no way i'd ever implement something like that ;)

Re: Stream.CopyStream - Miguel de Icaza

_Alan_ — Thu, 25 Sep 2008 05:05:07 -0000

Well, a TeeStream class wouldn't be that complex. A lot of the complexity that i saw in a class which allowed copying a stream an arbitrary number of times, with each copy having the ability to progress the initial stream would be gone. The implementation would be just read-once, write many. No threadin concerns there.

Something like:

public class TeeStream : Stream
{
public TeeStream (IEnumerable<Stream> destinationStreams)
{

}
}

would be fairly easy to implement. Something like that should already be in the BCL I suppose. There's no real reason why not.

Re: Stream.CopyStream - Miguel de Icaza

_Alan_ — Thu, 25 Sep 2008 08:14:10 -0000

Well, if all you're looking for is:

stream2.Write(stream1), then that's trivial enough to implement. However if you want something more along the lines of giving you three identical copies of the same stream so you can independently read from the copies and progress the initial stream, then it's a lot harder.

byte[] bytes = GetData();
MemoryStream a = new MemoryStream(bytes);
MemoryStream b = new MemoryStream(bytes);
MemoryStream c = new MemoryStream(bytes);

If you want a CopyStream that essentially does the above except using a Stream as the base rather than a byte[] as the base, the task is very difficult.

Re: Stream.CopyStream - Miguel de Icaza

_Alan_ — Thu, 25 Sep 2008 18:47:28 -0000

Ah, see that's where i think where we differ. That's just a simple myStream.Write (otherStream). It's completely different to a TeeStream or SplitStream as i described earlier ;) I did say that a writing the contents of one stream to another was easy, but i didn't think that's what was being asked in the original question. Maybe i'm wrong there.

Re: Mono 2.0 is out! - Miguel de Icaza

_Alan_ — Mon, 06 Oct 2008 18:13:58 -0000

Just build your application as normal, copy the resulting compiled file to Linux/MacOS and run it. Voila, you're done. The only thing you have to be careful about is calling native windows libraries through P/Invoke and hardcoding in windows-isms like hardcoding paths like C:\MyFolder

Re: Cartoon Network's Kid's MMO and Mono. - Miguel de Icaza

_Alan_ — Thu, 22 Jan 2009 10:45:17 -0000

Windows and Mac actually.

Re: Monday Mystery: Poetry Showing up on my Surveys. - Miguel de Icaza

_Alan_ — Mon, 06 Apr 2009 17:09:19 -0000

That which they have done
Was just a bit of may fun
Hope you enjoyed the show.

Re: Monday Mystery: Poetry Showing up on my Surveys. - Miguel de Icaza

_Alan_ — Tue, 07 Apr 2009 08:27:51 -0000

Nah, i just wrote the one on this blogpost to keep with the theme ;) I've no idea who actually wrote them all. Fair play to them though.

Re: Innovation - Miguel de Icaza

_Alan_ — Thu, 07 May 2009 13:42:40 -0000

It's hard to refute a claim that you're not innovating if you don't reference the word 'innovate' in your rebuttal ;)

Re: Moonlight 2 Preview 2 - Miguel de Icaza

_Alan_ — Wed, 13 May 2009 03:59:42 -0000

Yup, small testcases would be great for this. It sounds like it could be my area too ;) Either file a bug or send a quick email to the moonlight mailing list with the testcase + description.

Re: Moonlight 2 Preview 2 - Miguel de Icaza

_Alan_ — Wed, 13 May 2009 08:54:56 -0000

I'm sure you realise that moonlight is a browser plugin which enables you to view silverlight content on the web, so a browser is kind of a prerequisite if you want to use moonlight. So what you probably meant to ask is 'When will the moonlight plugin support $INSERT_BROWSER_HERE' ?

Re: TreemapViewer: Building Silverlight Applications on Unix - Miguel de Icaza

_Alan_ — Mon, 20 Jul 2009 18:54:16 -0000

Feature request, can you use a ScrollContentPresenter (or maybe just use dynamic limits for the height of the control). For those of us with small laptop screens, we can't click/see the bottom of the treemap :'(

Also, by any chance are you setting Grid.ShowGridlines to true (you shouldn't!), or is my local moon just a bit weird?

Re: MonoTouch: Mono on iPhone closed preview - Miguel de Icaza

_Alan_ — Mon, 03 Aug 2009 18:31:18 -0000

I assume you mean the accidental exclusion of some (brand new never before released) source files from the release tarball. While this is a regrettable oversight, it's hardly a fiasco. The issue was fixed a mere 10 days later. Slightly irritating, yes. A world-ending fiasco, not quite ;) It just meant that the first ever mono release of the code was 10 days later than expected.

Re: MonoTouch: Mono on iPhone closed preview - Miguel de Icaza

_Alan_ — Tue, 04 Aug 2009 05:21:14 -0000

iTouch is so much more sexual. Especially when people ask you "Can iTouch it?" when they see you holding your iTouch.

Re: MonoTouch: Mono on iPhone closed preview - Miguel de Icaza

_Alan_ — Wed, 05 Aug 2009 18:34:07 -0000

If there are any areas in particular that you feel are in danger of being neglected, you're perfectly free to commit patches to fix bugs and enhance performance.

Personally speaking, I think the best way to find bugs is to make
mono run on more platforms. If it takes 10 man weeks to port mono to the iPhone and as a result it gains 1000 daily users, surely that's well worth the effort. Though I suspect mono already has far more users on the iPhone than that - unity is already there.

Re: MonoTouch Resources - Miguel de Icaza

_Alan_ — Tue, 01 Sep 2009 21:11:40 -0000

It's special because now everyone knows how to use big fancy widgets in their own code. That's why samples doing fancy things are great!

Re: Compile Mono SVN Head on Windows

_Alan_ — Mon, 31 Jul 2006 19:06:40 -0000

Woo, after 2 long hard days of trying and failing, i finally managed to compile mono for windows on windows. Only worked when i did exactly as he did, with the exact same paths. Cygwin is a monster :(

Re: Take this Apple fanboys (or how sad this world is)

_Alan_ — Fri, 21 Nov 2008 09:35:24 -0000

Yay! Now i don't have to watch the content that I bought with my hard earned cash :D What a time saver!

Re: Take this Apple fanboys (or how sad this world is)

_Alan_ — Fri, 21 Nov 2008 22:10:00 -0000

"At least pretty much all monitors and projectors sold now are HDCP compliant..."

So what? I bought a nice TV 3 years ago, why should I have to fork out another few hundred/thousand euro to buy another TV to replace my perfectly good TV just so I can watch my legally purchased content? There are plenty of HD TVs out there without HDMI support.

Re: Take this Apple fanboys (or how sad this world is)

_Alan_ — Mon, 24 Nov 2008 11:13:05 -0000

Copy protection is mandatory on blu-ray discs, even for homemade movies. Or at least that was true the last time I read up on it.

Re: openSUSE 11.1 - A Disappointment

_Alan_ — Tue, 13 Jan 2009 20:55:53 -0000

You have to blacklist the new ath5k module before madwifi will be allowed load and take over your wireless. I got stung with this one.

Re: Phalanger on Mono (part 2)

_Alan_ — Thu, 22 Nov 2007 09:30:41 -0000

[quote]
There are also a few typedefs in the headers that compile to two different sizes between 32bit and 64bit platforms so I have to declare two versions of the same p/invoke calls on some occasions and use one or the other if the code is running on 32bit or 64bit.
[/quote]

Well, one trick is to have a native wrapper library which exposes a single API which does not have a change in size between 32bit/64bit platforms and then that native library will interop with your existing C++ code.

The size of 'long' in your C++ code will be the same as in the wrapper library, so you'll have no troubles interoping there, and your wrapper library will just expose it as int32_t or int64_t as required, so you are guaranteed fixed size variables.

Then, the C# code P/Invokes your wrapper library on all platforms, so you only need 1 set of p/Invokes in C# and you don't need runtime detection.

Alternatively, if you don't care about windows64 support, just represent a 'long' as an IntPtr in your C# code and you support all 32bit windows systems and all platforms with sizeof(pointer) == sizeof(long). Which is everything except win64.

Hope that makes sense.