Re: [Mono-dev] GSOC for Interactivre C#/F#/IronPython Console
Hi, Please send your proposal through the official GSoc portal: http://www.google-melange.com/gsoc/homepage/google/gsoc2011 Details of the proposal will be discussed in that portal after it's posted. Thanks! El dc 06 de 04 de 2011 a les 04:05 +0300, en/na Tayfur Yilmaz va escriure: Hi Everyone ı send my aproach for my app Firstly ı write some code for console app for Pardus Project and ı'm experinenced for talking backed application with new app so ı hava some idea for this project and write my proposal this idea. Example for Shell usage my aproach algoritmic analyze with coding Python (it's only example) Firstly for support a lot of language usage in Mono we need same layer and we define it so when we add different language usage for shell in project we have standart class and functions Example base.py class getAssembly(self): def __init__(self): pass def xxx(self): pass def yyy(self): pass class getCultureVersion(self): def __init__(self): pass def xxx(self): pass def yyy(self): pass class EnvironmentPath(self): def __init__(self): pass def xxx(self): pass def yyy(self): pass class ShellScreen(self): def __init__(self): pass def xxx(self): pass def yyy(self): pass IronPython.py,CSharp.py,FSharp.py #some spesific functions #some implementaions #some fields class getAssembly(base.getAssembly): # for IronPython code def __init__(self): pass @override def xxx(self): pass @override def yyy(self): pass class ShellScreen(base.ShellScreen) # for shell graphic designer and you integrated and decorated for IronPython def __init__(self): pass @override def xxx(self): pass @override def yyy(self): pass and so so so. And I solve some problem this approach when calling different attribute program do not make a bug for generally system and ıt's plugin based development and ı want to write some test(TDD) So my second aproach for C#/F#/IronPython ı think some usefeul scripts present to developer example I sometime write Django app ı use django-command-extensions it's very useful for developer with some scripts Example we management commands, additional database field And I think it's a plugin for shell and we add this app plugin repository so when developers need this app people install it.(Mono Plugin Repository) I write some examples code and uml diagram for this project I wii send it with my proposal and Any mentors discuss this approach with me and say some suggestions for me ? Thanks alot Best Regards ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Debugger crashes while debugging ASP.NET app
El dj 13 de 01 de 2011 a les 13:21 -0800, en/na passiday va escriure: Hello, I'm experiencing this weird debugger crashing. Spent now about 4 hours trying to work it out, and no luck. I'm really betting on this mailing list... So, this problem is there since I have installed MonoDevelop on my Ubuntu 10.10 64bit. I am trying to debug ASP.NET application - setting breakpoints, checking watches, stepping through the code line by line. So, I can successfully build my app, and run it in debug mode, it hits the first breakpoint, I can check the watches. Bud when I hit the Step over, the app immediately crashes. No info is dumped in Application Output pad. Funny thing is that very rarely it doesn't crash and lets me step over several lines, until the next breakpoint is hit and then crashes again, when trying to step further. Very annoying. Basically I am limited to one breakpoint for debugging, or to use awkward tools like dumping the debug variables to file or database. Does somebody have any clue, what's going on here? I know I am giving very little information on this crash. Maybe you can suggest how I can extract more information to supply to the case. Try running MonoDevelop from a terminal, and see which output you get. Also make sure you have the latest MonoDevelop and Mono. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Debugger not working on trunk?
Hi The debugger from trunk is not working for me at all. I'm trying the mdb command line debugger. It just hangs when doing 'run' on the most simple hello world app. Is anybody else experiencing this problem or am I the only one? Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installers
El dl 18 de 05 de 2009 a les 21:13 -0400, en/na Miguel de Icaza va escriure: I could see Mono.Addins going either way. It probably is used by enough Gtk# apps to justify it being in the Gtk# installer. My only concern with Mono.Addins is that once we ship it, it is effectively set in stone (or we have to incrementally add new versions of it, one for each API breakage). The question is whether Mono.Addins API is ready to be frozen or not. Yes, it is. The api has been stable since the first release. All changes have been backward-compatible additions. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-find-(provides|requires)
El dv 12 de 12 de 2008 a les 08:56 -0700, en/na Andrew Jorgensen va escriure: There are some significant problems with the mono-find-(provides| requires) scripts as they exist now. Some examples will illustrate the problem best: smuxi requires mono(log4net) which is provided by log4net but it is also provided by mojoportal. If you install mojoportal and then smuxi you will not get log4net and smuxi will not run. As a stop-gap we currently filter the provides to remove things likelog4net from the provides list of mojoportal, for instance, but this is hacky and difficult to maintain. The first logical step is to modify mono-find-provides so that it does not emit a provides for anything which is not in the gac. This has the following problem: monodevelop-boo requires mono(MonoDevelop.Core) but if mono-find-provides does not emit provides for things not installed in the gac then nothing provides mono(MonoDevelop.Core). We could manually say that monodevelop provides mono(MonoDevelop.Core) but this would be error-prone and difficult to maintain, particularly as API versions may change between releases and the packager has no easy way to see that change. What's special about monodevelop-boo is that it is an add-in, and add-ins depend on private (non-gac) assemblies of the applications they extend. I think the best solution is to have a tool which can detect add-ins and extract information about what they provide/require. Add-ins have an ID and a version number, and explicit information about which other add-ins they depend upon (with version numbers too). So it makes sense to use that information when building package dependencies. There is already a tool called mautil which can detect and show information about add-ins. You can run 'mautil info some.dll' and it will print the header of the add-in and some other information. I can implement a new option in that command to show the list of provides/requires in a way that can be easily parsed by mono-find-provides/requires. Mono.Addins supports several ways of declaring add-ins and dependencies. It can be done with an standalone xml manifest, or with an xml manifest embedded as resource, or using custom attributes. mautil would have to be used to check every assembly, but also all .addin and .addin.xml files. Improving mono-find-provides/requires in this way would be useful not only for MD, but also for any application based on Mono.Addins. Perhaps there's a way to check if a particular requirement is going tobe satisfied from the gac or from some other location and not emit arequires if it's not satisfied by the gac? Then packagers would have to manually add a requires on the package that provides the assembly. Also not desirable I think. Another option would be to insist that MonoDevelop installMonoDevelop.Core to the gac but maybe that's undesirable. Or maybe itis? Please let me know if that's a good solution. I don't know how best to solve this issue but it needs to be solved. As more mono-based packages are added to linux distributions the problem will grow. Please share your well-reasoned ideas and / or proposed patches. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
El dc 12 de 11 de 2008 a les 10:43 +0100, en/na Rolf Bjarne Kvinge va escriure: Hi, As one of the true maintainers of classlibs I'm completely against ideas to drop cygwin support as it completely destroys my hacking life (note that I don't mean I dislike adding VS build support), but anyways here I agree with jpobst on the part to keep using dll.sources. Here is what I do for adding new source files into svn: - Update *.dll.sources file: ls ../../build/common/*.cs */*.cs | sort System.Foo.Bar.dll.sources make - Collect which files should be mentioned in ChangeLog: svn diff FooBar.dll.sources - copy the rectangle(s) on the console output - Add new files to svn (and svn propdel svn:executable): copypaste those lines in svn add command line. Can these tasks ever easier by switching to your beautiful xml csproj? In MWF land did we create csproj-sources converter? In MWF land there's a sources-csproj converter. In vbnc land there's a vbproj-sources converter. I guess it depends on whoever is maintaining the code. IMHO as a starter it would be nice to have csproj's for all classlibs in svn, generated automatically in the makefiles (they way it's done in MWF), especially now that MD doesn't seem to be able to open the Makefiles anymore I'm not aware of any problem opening Mono's Makefiles. (this isn't only for VS people, it would be useful for MD people too). Rolf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins suppress console window showing
Fixed. Thanks! El dv 04 de 07 de 2008 a les 01:11 +0300, en/na Vladimir Dimitrov va escriure: Hello guys, Recently I started using Mono.Addins in my application and it looks very good. But as the application is primary used under windows (should be working fine under Linux too) I get an annoying console window showing when I run: AddinManager.Initialize (); And then another one when I run: AddinManager.Registry.Rebuild (null); I noticed in the code that at some point the .dll executes itself in a separate process ??!?! So if we add the following line: process.StartInfo.CreateNoWindow = true; to the file Mono.Addins/Mono.Addins/Database/SetupProcess.cs this would suppress the window to show under Window and should not cause any other complications. Please let me know what you think. Best regards, Vladimir Dimitrov P.S. I tried compiling my own copy with the change but it didn’t worked because when the process was trying to execute the .dll I compiled an exception was throws saying this is not a valid windows app. Maybe I need to compile it to .exe and just rename it? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins suppress console window showing
I'll commit the fix. Thanks!!! El dv 04 de 07 de 2008 a les 10:10 +0300, en/na Vladimir Dimitrov va escriure: Thanks Brad, Yes that worked and I don't see any problems with the line that I talked about being added so if the developer of this library is somewhere around he could add the change to the main source so everybody can get the fix. - Vlad -Original Message- From: Brad Taylor [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 5:31 AM To: Vladimir Dimitrov Cc: Mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono.Addins suppress console window showing Hey Vlad, Recently I started using Mono.Addins in my application and it looks very good. But as the application is primary used under windows (should be working fine under Linux too) I get an annoying console window showing when I run: snip You can also compile Mono.Addins as a winexe target to suppress the console. You'll probably have to rename it to a .dll afterwards if you compile under Windows. Hope this helps, -Brad No virus found in this incoming message. Checked by AVG. Version: 8.0.134 / Virus Database: 270.4.4/1531 - Release Date: 02.7.2008 г. 19:02 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem enabling Release Configuration in Monodevelop
You can change the active configuration using the combobox in the build toolbar. El ds 10 de 05 del 2008 a les 14:39 -0700, en/na Travis Miller va escriure: I just freshly installed Ubuntu 8.04 on my desktop (not an upgrade). Mondevelop runs fine except for one problem. When I try to switch from Debug to Release Configuration under options for a project all it says is Rmove or Rename in reference to the configuration. It used to be that right clicking on the Release configuration gave the option of enabling that configuration. Now however it does not. This is pretty much a show stopper as not being able to get a release exe out of the IDE makes it little more than worthless. Travis Miller ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono HEAD eating all CPU
Hmm, looks like I can repro anymore after updating again. El dc 07 de 05 del 2008 a les 04:24 +0200, en/na Lluis Sanchez Gual va escriure: I updated mono to HEAD and now MonoDevelop eats all CPU when running. I think this is caused by the InotifyWatcher code, since if I define MONO_MANAGED_WATCHER=1 everything works fine. This is the managed stack trace of the thread waiting on the watcher: tid=0x0x47432b90 this=0x0x488678: at (wrapper managed-to-native) System.IO.InotifyWatcher.ReadFromFD (intptr,byte[],intptr) 0x4 at (wrapper managed-to-native) System.IO.InotifyWatcher.ReadFromFD (intptr,byte[],intptr) 0x at System.IO.InotifyWatcher.Monitor () [0x00010] in /home/lluis/work/mcs/class/System/System.IO/InotifyWatcher.cs:369 at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) 0x And this is the stack trace shown by gdb. That mono_thread_interruption_checkpoint_request call looks weird to me. #0 0xe410 in __kernel_vsyscall () #1 0x4020203b in read () from /lib/libc.so.6 #2 0x4639d7fd in ?? () #3 0x in ?? () #4 0x007ae010 in ?? () #5 0x1000 in ?? () #6 0x408b40aa in ?? () #7 0x007ae010 in ?? () #8 0x0943dcf0 in ?? () #9 0x0943dcf0 in ?? () #10 0x081008c3 in mono_thread_interruption_checkpoint_request ( bypass_abort_protection=-9) at threads.c:3449 #11 0x4639d71c in ?? () #12 0x in ?? () #13 0x007ae000 in ?? () Any clue? Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono HEAD eating all CPU
I updated mono to HEAD and now MonoDevelop eats all CPU when running. I think this is caused by the InotifyWatcher code, since if I define MONO_MANAGED_WATCHER=1 everything works fine. This is the managed stack trace of the thread waiting on the watcher: tid=0x0x47432b90 this=0x0x488678: at (wrapper managed-to-native) System.IO.InotifyWatcher.ReadFromFD (intptr,byte[],intptr) 0x4 at (wrapper managed-to-native) System.IO.InotifyWatcher.ReadFromFD (intptr,byte[],intptr) 0x at System.IO.InotifyWatcher.Monitor () [0x00010] in /home/lluis/work/mcs/class/System/System.IO/InotifyWatcher.cs:369 at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) 0x And this is the stack trace shown by gdb. That mono_thread_interruption_checkpoint_request call looks weird to me. #0 0xe410 in __kernel_vsyscall () #1 0x4020203b in read () from /lib/libc.so.6 #2 0x4639d7fd in ?? () #3 0x in ?? () #4 0x007ae010 in ?? () #5 0x1000 in ?? () #6 0x408b40aa in ?? () #7 0x007ae010 in ?? () #8 0x0943dcf0 in ?? () #9 0x0943dcf0 in ?? () #10 0x081008c3 in mono_thread_interruption_checkpoint_request ( bypass_abort_protection=-9) at threads.c:3449 #11 0x4639d71c in ?? () #12 0x in ?? () #13 0x007ae000 in ?? () Any clue? Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Mono 1.9 / MD Idea
El ds 05 de 04 del 2008 a les 15:13 +0200, en/na Petit Eric va escriure: Hi folk I have folowed this step and have a little trouble. My system is MDV 2008, after a fresh install i had Mono 1.25 and MD , located in /usr/ dir, i think about trying mono 1.9, so uninstall all rpm, download the linux generic install from mono and install it in /opt/ dir. When starting MD in the good environment (/opt/) i have error message about file in /usr/lib/monodevelop Knowing the error message you got would be helpful. So i delete/clean evrything in ~/.config about MD/Mono and then no more problem, so i conclude there is some config file with absolute path and/or environment var. It isn't possible to use the startup path than the one in the config files? Well, I don't know which config path is that. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins
El dg 06 de 04 del 2008 a les 12:23 +0200, en/na Steinar Herland va escriure: Please forgive me for not sending this directly to http://groups.google.com/group/mono-addins - Only members can send to the list. The files - Mono.Addins.Database\IAssemblyReflector.cs - Mono.Addins.Database\DefaultAssemblyReflector.cs .. are not included in Mono.Addins.csproj. Can somebode please add them? Done. I need to use the svn-version of Mono.Addins because the TypeExtensionNode now exposes the type - Which can then be used by www.codeplex.com/unity to construct / resolve the object. Btw: Anybody know when the next version of Mono.Addins is scheduled for release? There are a couple of issue I want to fix. Maybe in a month or so. Steinar Herland CTO, www.gecko.no ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoDevelop] Soc 2008 idea: Universal graphical Framwork
A user interface designer is not like a drawing tool. The controls you put in the design surface must look and behave exactly like the controls at run-time. They are not graphical representations of the run-time controls, they are the *real* controls running in a special design mode. To do what you propose you would need to replicate gtk#, winforms and any other widget library you want to support using the designer framework. Even if you do that (which would take several years) it wouldn't work for custom widgets which use custom rendering. MonoDevelop already provides a toolbox and a property grid which can be shared by all designers. There isn't much more you can share. Lluis. El dj 27 de 03 del 2008 a les 12:48 +0100, en/na Gryffus va escriure: Wow this would be great!! Would be possible to implement later winforms designer (someone worked on it, but i dont know why it disappeared) and qt4 designer?? :-)) Gfs Sharique uddin Ahmed Farooqui napsal(a): Hi, We need different types of graphical designers like, xml designer, class designer, xaml designer, moonlight designer, etc. I think we should have a base framework, which will provide basic features like canvas and few controls and Monodevelop addin api. So that one can easily add there desired designer in monodevelop (a PCB designer for example). What are ur views friends? ___ Monodevelop-list mailing list [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/monodevelop-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
