It was indeed fixed. Sorry, I forgot to close that one.
Carlos.
2009/12/9 Oskar Berggren
> The release notes lists the following issue as fixed:
> 467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView
> in VirtualMode uses too much memory and is slow
>
> But the bug report is
Kris,
Apologies, this was an error in the release notes. The first release on OSX
with support for the debugger will be 2.6
Geoff
On 2009-12-09, at 10:40 PM, Kris Ray wrote:
>
> The release notes say that debugging works on OSX now when logged in as root.
>
> I just installed mono 2.4.3 a
On Wed, Dec 9, 2009 at 10:40 PM, Kris Ray wrote:
>
> The release notes say that debugging works on OSX now when logged in as root.
>
> I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2.
>
> I enabled the root account, then logged in as root.
>
> I then created a console a
The release notes say that debugging works on OSX now when logged in as root.
I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2.
I enabled the root account, then logged in as root.
I then created a console app in monodevelop and put in breakpoints.
The menu under "r
There were two commits to SVN with regards to this bug so it looks like it
was accidently not closed. CC'ing the guy who committed those fixes as he'd
be the one to know whether it should be closed or not.
Alan.
On Wed, Dec 9, 2009 at 10:41 PM, Oskar Berggren wrote:
> The release notes lists the
The release notes lists the following issue as fixed:
467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView
in VirtualMode uses too much memory and is slow
But the bug report is still marked as NEW and there is no comment
indicating that a fix has been checked in. What is the inte
Yesterday we released Mono 2.4.3. This release contains a large number
of bug fixes, including fixes for security bugs.
The release notes are here:
http://go-mono.com/archive/2.4.3
and downloads are available here:
http://go-mono.com/mono-downloads/
We have not released LiveCD or Applia
On 09.12.2009 16:20, Leszek Ciesielski wrote:
>> This loop will consume a lot of resources as the runtime have to decode and
>> load all types in the assembly before returning it.
>>
> This foreach loop is a common pattern for loading subclasses/plugins
> from an assembly, is there a better pattern
On Wed, 2009-12-09 at 16:20 +0100, Leszek Ciesielski wrote:
> This foreach loop is a common pattern for loading subclasses/plugins
> from an assembly, is there a better pattern for this?
Yes: assembly-level attributes.
http://weblogs.asp.net/justin_rogers/articles/61042.aspx
See the "1.
On Wed, Dec 9, 2009 at 3:38 PM, Rodrigo Kumpera wrote:
>
>
> On Wed, Dec 9, 2009 at 12:00 PM, Babbage Linden
> wrote:
>>
>> The code I'm using for loading is:
>>
>> public Script(string class_name, byte[] class_data,
>> ref long event_handlers)
>> {
>> Init();
>>
Hi,
> Sorry about that. I tried debugging it back then, but couldn't find
> out the cause of the
> problem, it seemed like memory corruption inside the GC data structures.
thanks for your comment on that. Although we added a workaround for that
particular problem in our software, this cannot be
On Wed, Dec 9, 2009 at 12:00 PM, Babbage Linden wrote:
>
> The code I'm using for loading is:
>
> public Script(string class_name, byte[] class_data,
> ref long event_handlers)
> {
> Init();
> Assembly assembly = Assembly.Load(class_data);
>
2009/12/9 APS :
> For sure I can pass a test case, is better that I file a bug report? I think
> that Mono team already knows where datasets are slower than MS.Net and maybe
> can suggest me some "best practice".
> Btw with the code provided below with MS.Net on a standard developer machine
> and M
2009/12/1 Zoltan Varga
> Hi,
>
> It is possible that you are using AppDomain.AssemblyLoad which is called
> every time an
> assembly is loaded ? Or a profiler callback ?
>
>
The code I'm using for loading is:
public Script(string class_name, byte[] class_data,
ref long ev
2009/12/1 Zoltan Varga
> On Tue, Dec 1, 2009 at 6:02 PM, Babbage Linden wrote:
>
>> Hi all,
>>
>> I'm currently investigating a performance problem which is causing complex
>> objects in Second Life containing many scripts to take a long time to load.
>>
>> We embed Mono in the Second Life simula
Thank both of you for helping me a lot.
--
View this message in context:
http://old.nabble.com/Internal-Call-tp26691444p26710312.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.xi
For sure I can pass a test case, is better that I file a bug report?
I think that Mono team already knows where datasets are slower than
MS.Net and maybe can suggest me some "best practice".
Btw with the code provided below with MS.Net on a standard developer
machine and Mono on a bi-processor t
On Dec 9, 2009, at 4:35 AM, Robert Jordan wrote:
> Dexter Yao wrote:
>>
>> Is there a another better way to call from C#( managed code ) by
>> passing the
>> pointer( IntPtr in C# ) of one C++ object and invoke its method?
>> ( like the
>> Lua does )
>> Looking forward to your reply.
>
>
Dexter Yao wrote:
>
> Is there a another better way to call from C#( managed code ) by passing the
> pointer( IntPtr in C# ) of one C++ object and invoke its method? ( like the
> Lua does )
> Looking forward to your reply.
There is no other way to invoke arbitrary C++ methods, but you
could desig
19 matches
Mail list logo
