I filed a bugreport and suggested a fix
https://bugzilla.xamarin.com/process_bug.cgi
I removed the html encoding when the text is written on the inner html
part of the tag. It seems to work on my app that is pretty large.
As I have another wanna-be fix that I described here and on bugreports,
Sorry, wrong link
https://bugzilla.xamarin.com/show_bug.cgi?id=13592
At 10:45 30/07/2013, APS wrote:
I filed a bugreport and
suggested a fix
https://bugzilla.xamarin.com/process_bug.cgi
I removed the html encoding when the text is written on the inner html
part of the tag. It seems to work on
On 30/07/13 10:45, APS wrote:
I filed a bugreport and suggested a fix
https://bugzilla.xamarin.com/process_bug.cgi
I removed the html encoding when the text is written on the inner html
part of the tag. It seems to work on my app that is pretty large.
As I have another wanna-be fix that I
I get the same problem with MonoDevelop after installing from source to
/usr/local. MonoDevelop 2.8.6.3 on KUbuntu 12.04.
I'm also interested in hearing about development workflow for
mscorlib.because I'm tackling some bugs myself.
On Sun, Jul 28, 2013 at 1:27 AM, jean-michel.perr...@csiro.au
I'm attempting to fix https://bugzilla.xamarin.com/show_bug.cgi?id=12552and
https://bugzilla.xamarin.com/show_bug.cgi?id=12551. Console, ConsoleDriver,
and the IConsoleDriver implementations make the flawed assumption that is
console is a simple boolean value when standard input or standard output
On 28/07/13 01:39, Brian Vogel wrote:
I've been struggling to get a .NET 4.5 site running under Mono 3.0 .
The current sites are running on an older Cent OS 5.5 server, and I've
since decided to move to Cent OS 6.6 and rebuild the server from scratch
to eliminate all possible variables from
On 26 Jul 2013, at 13:48, Robert Jordan robe...@gmx.net wrote:
On 26.07.2013 14:09, jonat...@mugginsoft.com wrote:
// validate the Mono representatiom
int64_t ticks = DB_UNBOX_INT64(DBMonoObjectGetProperty(monoDateTime,
Ticks));
MonoString *monoString =
Write module buffering online video stream for the player. I write it as
follows:
Buffer.BlockCopy (buf, 0, _buffer, _length, length);
where:
buf-what record
_buffer - where to write
_length - buffer size
length - the length of bytes to write
Reads the bytes from buffer:
byte [] outbs = new
Hello,
I have now built rpm and deb packages of the latest Mono (3.2) and
MonoDevelop (4.0.10) on Open Build Service:
https://build.opensuse.org/project/show/home:tpokorra:mono
You can install it on Debian 6 and 7, Ubuntu 12.04 and 13.04, CentOS
6, Fedora 17 and 18.
If there is interest for a
const86 - your _length value could be going negative. This might be
interpreted as a very long length buffer, hence the 2 seconds.
Bob Davies
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Is there a reason your video source requires this technique to buffer? This
code is inefficient because:
1. It allocates a new buffer every time it reads from the source buffer.
2. It removes data from the source buffer by doing 2 more heap and block copies.
I'm pretty sure overlapping regions
I've never done that myself, but if I remember correctly, you're not supposed
to add the .so part. Just do [DllImport(libshared)]. That way, it's up
to the framework to figure out the right extension depending on the OS it
runs on.
In other words, that'd mean it can't find your file because it's
Dllimport tells the loader the library name.
A large combination of things work as library loading and shared objects
differ greatly on windows and unix.
On windows, the library could be installed in the side-by-side cache or in
the same folder as your assembly etc.
If you have a file called
On Jul 30, 2013, at 5:34 PM, Stifu st...@free.fr wrote:
I've never done that myself, but if I remember correctly, you're not supposed
to add the .so part. Just do [DllImport(libshared)].
Close; you should prefer [DllImport(shared)], with one exception. On Windows,
this will try to load
14 matches
Mail list logo
