From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: needed to have Graphics objects initialized from GDI specific data structures (HDC and HWND) to perform painting and in the case of owner-drawn elements we do not really control neither surface on which we are painting nor the moment when painting is started/finished. Some other SysDrawing objects (like Bitmap,Image, Font, Region) are also GDI depended from my point of view. So, IMO, the code for System.Drawing have to be compatible with Sys.Win.Forms and may be we need to separate SysDrawing like SFW is separated now ? Alexandre ----- Original Message ----- From: "Miguel de Icaza" To: "Gonzalo Paniagua Javier" Cc: "Mono Development" Sent: Friday, April 18, 2003 7:45 AM Subject: Re: [Mono-devel-list] New code for System.Drawing... > Hello, > > > > A while back I mailed in some patches for Bitmap.cs and Image.cs which > > > never seem to have made it into cvs. I am submitting them again, as > > > diffs against cvs head (attached). This patch allows bitmaps to be > > > loaded from disk, using Gdk. > > > > > > I need to get this working in Mono in order to run Flat Four (see > > > http://www.379.com/flatfour/) on Linux. If there is anything that I can > > > do to help get these patches into the next release, please let me know. > > > > Image.diff is ok (it's just a stuf), but Bitmap.diff would add a > > dependency on libgdk. > > > > We should not depend on that. > > My feelings is that we could live with the dependency in the meantime. > But Gonzalo is right in that we should consider what we will do in the > long term for implementing that functionality. The dependency is not > something everyone might be excited about. > > There is some reformatting of the code, large chunks of it that would > loose history. > > Miguel. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: needed to have Graphics objects initialized from GDI specific data structures (HDC and HWND) to perform painting and in the case of owner-drawn elements we do not really control neither surface on which we are painting nor the moment when painting is started/finished. Some other SysDrawing objects (like Bitmap,Image, Font, Region) are also GDI depended from my point of view. So, IMO, the code for System.Drawing have to be compatible with Sys.Win.Forms and may be we need to separate SysDrawing like SFW is separated now ? Alexandre ----- Original Message ----- From: "Miguel de Icaza" To: "Gonzalo Paniagua Javier" Cc: "Mono Development" Sent: Friday, April 18, 2003 7:45 AM Subject: Re: [Mono-devel-list] New code for System.Drawing... > Hello, > > > > A while back I mailed in some patches for Bitmap.cs and Image.cs which > > > never seem to have made it into cvs. I am submitting them again, as > > > diffs against cvs head (attached). This patch allows bitmaps to be > > > loaded from disk, using Gdk. > > > > > > I need to get this working in Mono in order to run Flat Four (see > > > http://www.379.com/flatfour/) on Linux. If there is anything that I can > > > do to help get these patches into the next release, please let me know. > > > > Image.diff is ok (it's just a stuf), but Bitmap.diff would add a > > dependency on libgdk. > > > > We should not depend on that. > > My feelings is that we could live with the dependency in the meantime. > But Gonzalo is right in that we should consider what we will do in the > long term for implementing that functionality. The dependency is not > something everyone might be excited about. > > There is some reformatting of the code, large chunks of it that would > loose history. > > Miguel. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: allways behave in the same way when running in your AppServer, in a standalone XSP server, in the Apache mod, or in any custom server application. However, an application server provides some extra services that can be very useful for some type of applications. For example: hosting of remote components. My document talks about this service because COM+ provides component hosting (hosted components are remotely accessible through DCOM and SOAP, but not remoting), although strictly speaking it is not part of EnterpriseServices. I think it is good to keep EnterpriseServices independent from any application server, it will give people more choice (choice between application servers, or choice to not use any application server at all). - Lluis. > > ----- Original Message ----- > From: "Lluis Sanchez" > To: > Sent: Wednesday, April 30, 2003 3:43 PM > Subject: [Mono-devel-list] Starting System.EnterpriseServices > > > > Hi all! > > > > Joshua Prismon and I have been thinking about the implementation of > > System.EnterpriseServices in Mono. The result is a couple of documents > that > > we'd like to share with you. The first one gives a high level overview > about > > a possible architecture and implementation strategy. The second one gives > > low level detail about the implementation. > > > > These are the documents: > > * Architecture and Implementation Strategy for Mono's > > System.EnterpriseServices > > > http://us.f1.yahoofs.com/users/a7c551c5/bc/ses/Mono+SES+architecture.PDF?bcbbCs.AzRQEThh4 > > > > * Proposed Design and Low Level Details for the Mono implementation of > > System.EnterpriseServices > > > http://us.f1.yahoofs.com/users/a7c551c5/bc/ses/Low+Level+Details+for+the+Mono+SES.PDF?bcbbCs.AsxV0.LKI > > > > There is also a wiki page with links on the mono wiki: > > http://www.nullenvoid.com/mono/wiki/index.php/EnterpriseServices. > > > > Please, send comments, ideas, corrections, so we can start working on it. > > > > Regards, > > Lluis. > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: seems clear to me that I need to use some specific header include paths and defines for Windows, but I haven't been able to get a combination that works yet. Does anyone have a Makefile I could use to compile the embed sample or cilc generated test on Windows, or if not does anyone have pointers to where I could gather this information? Best regards, -Candace From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: foreach (string source in fileNames) args.AppendFormat("'{0}' ",source); return args.ToString(); What am I doing wrong? Surely someone must have tested xsp on win32 with 0.25 before me? -Pelle -----Original Message----- From: Gonzalo Paniagua Javier [mailto:gonzalo at ximian.com] Sent: 1. juli 2003 02:27 To: Pelle Johnsen; Mono Development Subject: RE: [Mono-devel-list] xsp-0.4 + mono-0.25 on win32? El mar, 01-07-2003 a las 02:22, Pelle Johnsen escribi?: > Hi Gonzalo, > > Have tried that, but the mono.bat file prepends the directory with mcs.exe > to the path. I'm not sure I understand what this means... > > Even tried renaming mcs.exe - the mcs.bat still isn't run :( mcs.bat has to be in your PATH, mcs.exe doesn't. -Gonzalo From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: make[1]: Entering directory `/home/rafael/Projects/mcs/class/System.Data' MONO_PATH="../../class/lib:$MONO_PATH" mono ../../mcs/mcs.exe -g /nowarn:1595 /nowarn:0169 /nowarn:0109 /nowarn:0067 /nowarn:0649 /nowarn:0679 /noconfig /nowarn:0219 /nowarn:0168 /r:corlib.dll /r:../../class/lib/System.dll /r:System.Xml.dll /r:System.EnterpriseServices.dll /r:Mono.Data.Tds.dll /target:library /out:../../class/lib/System.Data.dll @System.Data.dll.sources System.Data/DataException.cs(18) error CS0122: `Locale' is inaccessible because of its protection level System.Data/ConstraintException.cs(18) error CS0122: `Locale' is inaccessible because of its protection level System.Data/DataRow.cs(172) error CS0122: `Locale' is inaccessible because of its protection level System.Data/DeletedRowInaccessibleException.cs(18) error CS0122: `Locale' is inaccessible because of its protection level ... System.Xml/XmlDataDocument.cs(485) error CS0122: `Locale' is inaccessible because of its protection level Compilation failed: 41 error(s), 0 warnings make[1]: Leaving directory `/home/rafael/Projects/mcs/class/System.Data' because System.Globalization.Locale is internal to corlib. What should we do? Can I add temporarily an internal Locale class to System.Data? Best Regards, Rafael Teixeira Brazilian Polymath Mono Hacker since 16 Jul 2001 _________________________________________________________________ MSN Messenger: instale gr?tis e converse com seus amigos. http://messenger.msn.com.br From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: CASE (CEE_ADD) ++ip; --sp; #define CEE_ADD_CHECK(t, A, B) CHECK_NONE #define CEE_ADD_OP(t, A, B) BINARY_OP (t, +, (A), = (B)) BINARY_NUMERIC_SWITCH (CEE_ADD, sp [-1], sp [0]); BREAK; CASE (CEE_SUB) ++ip; --sp; #define CEE_SUB_CHECK(t, A, B) CHECK_NONE #define CEE_SUB_OP(t, A, B) BINARY_OP (t, -, (A), = (B)) BINARY_NUMERIC_SWITCH (CEE_SUB, sp [-1], sp [0]); BREAK; CASE (CEE_MUL) ++ip; --sp; #define CEE_MUL_CHECK(t, A, B) CHECK_NONE #define CEE_MUL_OP(t, A, B) BINARY_OP (t, *, (A), = (B)) BINARY_NUMERIC_SWITCH (CEE_MUL, sp [-1], sp [0]); BREAK; CASE (CEE_DIV) ++ip; --sp; #define CEE_DIV_CHECK(t, A, B) \ do { \ /* check for division by zero */ \ if (VAL_TYPE (t) !=3D VAL_DOUBLE \ && READ_SV (t, (B)) =3D=3D (DATA_TYPE (t))0) \ THROW_DIV_BY_ZERO_EX (ip - 1); \ /* check for result type overflow (MIN/-1) */ \ if (VAL_TYPE (t) !=3D VAL_DOUBLE \ && READ_SV (t, (A)) =3D=3D VAL_MIN (t) \ && READ_SV (t, (B)) =3D=3D (DATA_TYPE (t))-1) \ THROW_ARITHMETIC_EX (ip - 1); \ } while (0) #define CEE_DIV_OP(t, A, B) \ do { \ if (VAL_TYPE (t) =3D=3D VAL_DOUBLE \ && READ_SV (t, (B)) =3D=3D (DATA_TYPE (t))0) \ /* A / 0.0 =3D> NaN ? */; \ BINARY_OP (t, /, (A), (B)); \ } while (0) BINARY_NUMERIC_SWITCH (CEE_DIV, sp [-1], sp [0]); BREAK; From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: /** stack value readers */ #define READ_I32(A) ((A).data.i) #define READ_I64(A) ((A).data.l) #define READ_DOUBLE(A) ((A).data.f) #define READ_NATI(A) ((DATA_TYPE (NATI))(((A).type =3D=3D VAL_I32) \ ? (A).data.i \ : (A).data.nati)) #define READ_SV(t, A) READ_##t ((A)) /** stack value writers */ #define WRITE_I32(A, v) ((A).data.i =3D (DATA_TYPE (I32))(v)) #define WRITE_I64(A, v) ((A).data.l =3D (DATA_TYPE (I64))(v)) #define WRITE_DOUBLE(A, v) ((A).data.f =3D (DATA_TYPE (DOUBLE))(v)) #define WRITE_NATI(A, v) ((A).type =3D VAL_NATI, \ (A).data.nati =3D (DATA_TYPE (NATI))(v)) #define WRITE_SV(t, A, v) WRITE_##t ((A), (v)) /** * Operation helpers: */ #define BINARY_OP_WITH_CHECK(t, op, A, B) \ do { \ op##_CHECK (t, (A), (B)); \ op##_OP (t, (A), (B)); \ } while (0) #define BINARY_OP(t, op, A, B) \ WRITE_SV (t, (A), READ_SV (t, (A)) op READ_SV (t, (B))); \ #define CHECK_NONE (0) /** * Binary numeric operations: */ #define BINARY_NUMERIC_RESULT_TYPE(A, B) \ (((A).type =3D=3D (B).type) ? (A).type : VAL_NATI) #define BINARY_NUMERIC_SWITCH(op, A, B) \ do { \ switch (BINARY_NUMERIC_RESULT_TYPE ((A), (B))) { \ case VAL_I32: BINARY_OP_WITH_CHECK (I32, op, (A), (B)); break; \ case VAL_I64: BINARY_OP_WITH_CHECK (I64, op, (A), (B)); break; \ case VAL_NATI: BINARY_OP_WITH_CHECK (NATI, op, (A), (B)); break; \ case VAL_DOUBLE: BINARY_OP_WITH_CHECK (DOUBLE, op, (A), (B)); break; \ default: ves_abort (); \ } \ } while (0) ________________________________________ From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Bernie = Solomon Sent: Wednesday, July 23, 2003 5:15 PM To: mono-devel-list at lists.ximian.com =A0 I attach quite a large patch for interp.c to primarily cope with 64 bit = big endian machines though it also includes some fixes to instruction = handling particularly for OVF instructions - and generating exceptions for some = other operations properly. I have tried to get instruction behaviour correct = re handing of native int correct as per the spec. Also every exit now goes = via a label (exit_frame) partly for debugging and also because in some experiments I wanted to add code for it. =A0 No doubt there may be issues with the way I have done things but I = though I'd post it for review. =A0 Bernie Solomon =A0 =A0 From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: 2003/08/13 Rafael Teixeira * mb-parser.jay: ReDim statement parses many variables now (but initializers aren't allowed) Erase statement implemented Lots of garbage (never reduced rules) deleted Reduce/Reduce problems eliminated (were due to having opt_modifiers duplicated inside property_declaration rule) * statement.cs : class Redim is prepared to have ReDim Preserve copying code called, but we need to check if that code is lying in Microsoft.VisualBasic.dll New class Erase One-and-a-half step closer... Best 'basics", Rafael Teixeira Brazilian Polymath Mono Hacker since 16 Jul 2001 _________________________________________________________________ MSN Messenger: instale gr?tis e converse com seus amigos. http://messenger.msn.com.br From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: real 15m2.682s user 7m59.260s sys 1m26.640s From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: real 9m11.497s user 7m46.800s sys 0m56.820s From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: real 2m50.530s user 0m54.830s sys 0m44.880s From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: real 1m50.614s user 0m50.630s sys 0m39.150s So, obviously your patch makes a huge difference. Thanks very much! :) --Todd From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: nunit files are not actually included in the mono build even though they are in cvs. As it turns out, we no longer have any non-gui registry settings, so I'll just proceed as planned and drop those things. We want to get away from the registry anyway, so we should be able to merge the two builds in the next release of nunit. Charlie Poole cpoole at pooleconsulting.com > -----Original Message----- > From: Nick Drochak [mailto:ndrochak at gol.com] > Sent: Tuesday, October 14, 2003 10:10 AM > To: 'Charlie Poole'; mono-devel-list at lists.ximian.com > Subject: RE: [Mono-devel-list] NUnit 2.1 > > > | -----Original Message----- > | From: Charlie Poole [mailto:cpoole at pooleconsulting.com] > | Sent: Wednesday, October 15, 2003 1:13 AM > | To: ndrochak at gol.com; mono-devel-list at lists.ximian.com > | Subject: RE: [Mono-devel-list] NUnit 2.1 > | > | > I assume the registry support is for the GUI, like a "Recent > Tests" menu > | > item. We don't have the GUI in mono CVS, so if you need a quick build > fix, > | > it might be enough to just delete those files. I haven't tried it > myself > | > however. > | > | Most of it is gui related, and I can work around the rest. That's what I > was > | doing till I noticed your CVS actually contains the code that > accesses the > | windows registry and saw a note that seemed to indicate it > builds. That's > | the > | part that's confusing me. I don't want to release an nunit for mono that > has > | less capability than what you guys are already doing. > > Well, we never used the windows GUI of NUnit with mono testing. > At least we > never really had it in CVS. We have just used nunit-console > until now; and > also gnunit. > > It definitely was building on linux before, but I don't think > those classes > were used at all by the mono runtime since we didn't use the GUI runner. > > In other words, I don't think we lose anything if you take out > the registry > stuff. > > HTH, > Nick D. > > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: s /html/cpgrfglobalassemblycacheutilitygacutilexe.asp /ir assemblyPath scheme id description Installs an assembly into the global assembly cache and adds a reference to count the assembly. You must specify the assemblyPath, scheme, id, and description parameters with this option. For a description of the valid values you can specify for these parameters, see the /r option.=20 Specifying this option is equivalent to specifying the /i and /r options together. /r [assemblyName | assemblyPath] scheme id description Specifies a traced reference to an assembly or assemblies to install or uninstall. Specify this option with the /i, /il, /u, or /ul options.=20 To install an assembly, specify the assemblyPath, scheme, id, and description parameters with this option. To uninstall an assembly, specify the assemblyName, scheme, id, and description parameters. To remove a reference to an assembly, you must specify the same scheme, id, and description parameters that were specified with the /i and /r (or /ir) options when the assembly was installed. If you are uninstalling an assembly, the tool also removes the assembly from the global assembly cache if it is the last reference to remove and if Windows Installer has no outstanding references to the assembly. The scheme parameter specifies the type of installation scheme. You can specify one of the following values:=20 UNINSTALL_KEY: Specify this value if the installer adds the application to Add/Remove Programs in Microsoft Windows. Applications add themselves to Add/Remove Programs by adding a registry key to HKLM\Software\Microsoft\Windows\CurrentVersion.=20 FILEPATH: Specify this value if the installer does not add the application to Add/Remove Programs.=20 OPAQUE: Specify this value if supplying a registry key or file path does not apply to your installation scenario. This value allows you to specify custom information for the id parameter.=20 The value to specify for the id parameter depends on the value specified for the scheme parameter:=20 If you specify UNINSTALL_KEY for the scheme parameter, specify the name of the application set in the HKLM\Software\Microsoft\Windows\CurrentVersion registry key. For example, if the registry key is HKLM\Software\Microsoft\Windows\CurrentVersion\MyApp, specify MyApp for the id parameter.=20 If you specify FILEPATH for the scheme parameter, specify the full path to the executable file that installs the assembly as the id parameter.=20 If you specify OPAQUE for the scheme parameter, you can supply any piece of data as the id parameter. The data you specify must be enclosed in quotation marks ("").=20 The description parameter allows you to specify descriptive text about the application to install. This information is displayed when references are enumerated. =20 From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: Performance: Strong name signature verification. All shared assemblies must have strong name signatures. These signature are verified when the assembly is installed into the gac. Once verified the signatures are not verified each time the assembly is referenced. In contrast, shared assemblies deployed outside the assembly have their signatures verified each time the assembly is loaded. Performance: Working set. If a large number of applications will be referencing a particular shared assembly, overall working set can be improved by using the gac. Because all applications will be loading the assembly from the same file path, the operating system will share the assemblys code pages among all callers. A commonly used WebForm control is a good example of an assembly where this benefit may apply. Management: Deploying bug fixes. Administrators can use the gac to deploy bug fixes intended to be picked up by all applications. By deploying the fix to the gac and stating the appropriate version policy in the machine configuration file, an admin can ensure that all applications on the machine will begin to use the fix. ********************************* more stuff related and only somewhat related. http://www.codeproject.com/dotnet/demystifygac.asp http://www.aspalliance.com/articleViewer.aspx?aId=76&vId=1&pId=-1 http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%2B%22Global+Assembly+Cache%22+%2Bassembly&btnG=Google+Search ************************************************************************************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ************************************************************************************************** --=__Part5709FDEC.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Description: HTML
Well I would say this (after reading everyone's comments), what is being missed here is the fact that the strong mane is the "final" key to tell one assembly from another.

Say I am a developer and I create assembly "system.dll". another developer creates another assembly "system.dll" what tells these two apart, not to mention the system.dll that comes with the runtime? Version number you say? OK. What if we are both version 2?

See how omiting the strong name breaks things down?

Next let's look at the multiple assemblies issue. By definition, the runtime should look in the local folders first, then the GAC. In the case of ASP.NET, the only way to have custom controls available across webs is to install them into the GAC unless you plan to copy them to each bin directory. Then you must be sure to update each one if you do.

With a single assembly in the GAC, you only have to wory about the one. And if you look at the GAC itself, you have to differentiate it with the Strong name as the final key.
 
Again, the runtime looks for a file named "system.dll" with a particular strong name not system.2.dll.
 
In short, I think the directory method is the way to go.
 
I may be way off base, but to me it keeps all the pieces in one place as organized more easily.
************************************************
From the GotDotNet Site (http://www.gotdotnet.com/team/clr/when_to_use_the_gac.aspx)...

      Performance: Strong name signature verification. All shared assemblies must have strong name signatures. These signature are verified when the assembly is installed into the gac. Once verified the signatures are not verified each time the assembly is referenced. In contrast, shared assemblies deployed outside the assembly have their signatures verified each time the assembly is loaded.

      Performance: Working set. If a large number of applications will be referencing a particular shared assembly, overall working set can be improved by using the gac. Because all applications will be loading the assembly from the same file path, the operating system will share the assemblys code pages among all callers. A commonly used WebForm control is a good example of an assembly where this benefit may apply.

      Management: Deploying bug fixes. Administrators can use the gac to deploy bug fixes intended to be picked up by all applications. By deploying the fix to the gac and stating the appropriate version policy in the machine configuration file, an admin can ensure that all applications on the machine will begin to use the fix.



*********************************
 
more stuff related and only somewhat related.
 
 
 
**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to anyone or make copies.
**************************************************************************************************
--=__Part5709FDEC.0__=-- From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: developer, I agree that mono 1.0 should correspond to .net 1.0, 1.1 to = 1.1, etc for compatibility (and marketing) reasons. Will a .90 Release just not cut it? And for that matter 1.09, etc?=20 Just a suggestion of course... -----Original Message----- From: ndrochak at gol.com [mailto:ndrochak at gol.com] Sent: Thursday, November 06, 2003 3:40 AM To: Rob.Tillie at Student.tUL.EDU; mono-devel-list at lists.ximian.com Subject: RE: [Mono-devel-list] Version moniker for Mono Release | -----Original Message----- | From: Rob.Tillie at Student.tUL.EDU [mailto:Rob.Tillie at Student.tUL.EDU] | Sent: Thursday, November 06, 2003 4:40 PM | To: nick at ingeniumgroup.com; mono-devel-list at lists.ximian.com | Subject: RE: [Mono-devel-list] Version moniker for Mono Release |=20 | Well, you've got a point, without a doubt. | But Miguel also has a point in that Mono should be releasing a stable | release very soon now... I believe Mono has a lot of momentum right = now, | by | waiting too long, that momentum could decrease, having the same = result by | losing a large user base... |=20 I agree completely. I didn't mean to imply delaying the release, only = to choose the name carefully. Regards, Nick D. _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: developer, I agree that mono 1.0 should correspond to .net 1.0, 1.1 to 1.1, etc for compatibility (and marketing) reasons. Will a .90 Release just not cut it? And for that matter 1.09, etc? Just a suggestion of course... -----Original Message----- From: ndrochak at gol.com [mailto:ndrochak at gol.com] Sent: Thursday, November 06, 2003 3:40 AM To: Rob.Tillie at Student.tUL.EDU; mono-devel-list at lists.ximian.com Subject: RE: [Mono-devel-list] Version moniker for Mono Release | -----Original Message----- | From: Rob.Tillie at Student.tUL.EDU [mailto:Rob.Tillie at Student.tUL.EDU] | Sent: Thursday, November 06, 2003 4:40 PM | To: nick at ingeniumgroup.com; mono-devel-list at lists.ximian.com | Subject: RE: [Mono-devel-list] Version moniker for Mono Release | | Well, you've got a point, without a doubt. | But Miguel also has a point in that Mono should be releasing a stable | release very soon now... I believe Mono has a lot of momentum right now, | by | waiting too long, that momentum could decrease, having the same result by | losing a large user base... | I agree completely. I didn't mean to imply delaying the release, only to choose the name carefully. Regards, Nick D. _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: retrieving objects from the GC, but i could be totally wrong. For some reason, under OSX, objects seem to be getting lost (null pointers to data coming up in ves_exec_method_with_context() and stackval_to_data()) while using the interpreter. I am using version 6.2 of the GC downloaded separately because the OSX build of the GC included with the runtime is currently broken. (WIll be filing a bug report soon, possibly with a patch because i fixed this once before but since lost the fixes :)) I have not tried running without the GC. This shouldn't do anything more than just allocate objects until the machine runs out of memory, correct? Is there a specific person or group that is working on the PPC port? I know Miguel said that the PPC port of the jit was planned to be done by the PDC, but didnt' specify who was doing it. rob From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: A conforming implementation may also include additional functionality that does not prevent running code written to rely solely on the profile as specified in this standard. For example, it may provide additional classes, new methods on existing classes, or a new interface on a standardized class, but it shall not add methods or properties to interfaces specified in this standard. So, for instance, if on mono somebody made the Object class implement a MonoSpecificObject interface, as far as I know the mono .NET implementation would still comply with the standard. Of course, this would not necessarily be a good idea, and it would not make you identify the platform, but only the CLI implementation... Probably the right thing would be having the necessary facilities for platform identification included in a future revision of the standard. Ciao, Massimiliano From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: I have come up with a way to build using ICU under cygwin. I downloaded the prebuilt VC6 binaries from the link on http://oss.software.ibm.com/icu/download/2.6.1/index.html. I installed this under cygwin's structure (I used /usr/local/icu as the root). Somewhere in your path put this script as icu-config (I chose /usr/local/bin/icu-config) having editted ICU_ROOT to wherever you installed ICU (this script is attached as well). #/bin/sh ICU_ROOT=/usr/local/icu case $1 in --cppflags) echo "-I$ICU_ROOT/include" ;; --ldflags) echo "-L$ICU_ROOT/lib -licuuc -licuin" ;; --version) grep '\' $ICU_ROOT/include/unicode/uversion.h | sed -e 's/.*"\(.*\)".*/\1/' ;; esac now you can rerun configure and this should detect the ICU installation properly and use it. -----Original Message----- From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com]On Behalf Of Giovanni Zito Sent: Saturday, January 03, 2004 5:16 AM To: Mono-devel-list at lists.ximian.com Subject: [Mono-devel-list] Build failed for mono 0.29 on Windows I'm trying to building mono 0.29 on Cygwin, with no success. Windows version: Windows XP with service pack 1 cygwin1.dll product version: 1.1.6 I started from mono packaged version, and used the following command line: ./configure --with-gc=included && make I've got the following error, while compiling libgc-mono (gcc version is 2.95.2-5) gcc -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE _VERSION=\"6.2\" "-DPACKAGE_STRING=\"libgc-mono 6.2\"" -DPACKAGE_BUGREPORT=\"Hans_Boehm at hp.com\" -DGC_WIN32_THREADS=1 -DNO_G ETENV=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STASIGNALS=1 -DNO_E XECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLL ECTABLE=1 -D_IN_LIBGC=1 -I./include -I./include -fexceptions -g -O2 -fexcept ions -c misc.c -Wp,-MD,.deps/misc.TPlo -DDLL_EXPORT -DPIC -o .libs/misc.lo misc.c:51: `PTHREAD_MUTEX_INITIALIZER' undeclared here (not in a function) So I switched on MinGW (latest version 3.01) with Cygwin. ./configure --with-gc=included && make (gcc version is 3.2.3) gcc -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE _VERSION=\"6.2\" "-DPACKAGE_STRING=\"libgc-mono 6.2\"" -DPACKAGE_BUGREPORT=\"Hans_Boehm at hp.com\" -DGC_WIN32_THREADS=1 -DNO_G ETENV=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STD LIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYP ES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EX ECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLE CTABLE=1 -D_IN_LIBGC=1 -I./include -I./include -fexceptions -g -O2 -fexcepti ons -c win32_threads.c -MT win32_threads.lo -MD -MP -MF .deps/win32_threads.TPlo -DDLL_EXPORT -DPIC -o .libs/win32_threads.lo win32_threads.c:406: conflicting types for `GC_CreateThread' include/gc.h:898: previous declaration of `GC_CreateThread' win32_threads.c:477: warning: static declaration for `thread_start' follows non-static make[3]: *** [win32_threads.lo] Error 1 Has anyone out there successfully build mono-029 on Windows? On the mono site there isn't a binary version for Windows.... this sounds very strange. Any kind of help will be appreciated. G.Z. From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: > cd > nmake -f NT_THREADS_MAKEFILE =20 After that copy Release/gc.lib and Release/gc.dll to /usr/local/lib. =20 Also you should install include files into /usr/local/include. Change to = the folder where you extracted gc6.2 tarball and type: =20 mkdir -p /usr/local/include cp include/gc.h /usr/local/include cp include/gc_config_macros.h /usr/local/include cp include/gc_local_alloc.h /usr/local/include cp include/gc_pthread_redirects.h /usr/local/include cp include/gc_typed.h /usr/local/include cp include/leak_detector.h /usr/local/include =20 mkdir /usr/local/include/gc cp include/gc.h /usr/local/include/gc cp include/gc_alloc.h /usr/local/include/gc cp include/gc_allocator.h /usr/local/include/gc cp include/gc_amiga_redirects.h /usr/local/include/gc cp include/gc_backptr.h /usr/local/include/gc cp include/gc_config_macros.h /usr/local/include/gc cp include/gc_cpp.h /usr/local/include/gc cp include/gc_gcj.h /usr/local/include/gc cp include/gc_inl.h /usr/local/include/gc cp include/gc_inline.h /usr/local/include/gc cp include/gc_local_alloc.h /usr/local/include/gc cp include/gc_mark.h /usr/local/include/gc cp include/gc_pthread_redirects.h /usr/local/include/gc cp include/gc_typed.h /usr/local/include/gc cp include/leak_detector.h /usr/local/include/gc cp include/new_gc_alloc.h /usr/local/include/gc cp include/weakpointer.h /usr/local/include/gc =20 =20 6) Get the ICU library from = http://oss.software.ibm.com/icu/download/2.6.1/index.html =20 I've got icu-2.6.1-Win32_msvc7.zip, although ICU version compiled with = msvc 6.0 should go well. Follow the instructions below, from Bernie Solomon: =20 [ I have come up with a way to build using ICU under cygwin. I downloaded the prebuilt VC6 binaries from the link on = http://oss.software.ibm.com/icu/download/2.6.1/index.html. I installed this under cygwin's structure (I used /usr/local/icu as the = root). Somewhere in your path put this script as icu-config (I chose = /usr/local/bin/icu-config) having edited ICU_ROOT to wherever you = installed ICU (this script is attached as well). #/bin/sh ICU_ROOT=3D/usr/local/icu case $1 in --cppflags) echo "-I$ICU_ROOT/include" ;; --ldflags) echo "-L$ICU_ROOT/lib -licuuc -licuin" ;; --version) grep '\' $ICU_ROOT/include/unicode/uversion.h | sed = -e 's/.*"\(.*\)".*/\1/' ;; esac Now you can rerun configure and this should detect the ICU installation = properly and use it. ] =20 =20 Important: remember to "chmod u+x /usr/local/bin/icu-config" otherwise = the mono configure script will be unable to detected ICU ! =20 Thanks to Bernie Solomon and Daniel Morgan to point me in right = direction in order to successfull install ICU on cygwin =20 =20 Building mono =20 You are now ready to build mono. =20 $ cd ~src/mono-0.29 $ ./configure --with-gc=3Dboehm CPPFLAGS=3D-I/usr/local/include = LDFLAGS=3D-L/usr/local/lib $ make $ make install =20 =20 Building mcs =20 To build mcs I used csc.exe (the C# compiler V7.10.3052.4) and = ResGen.exe (Resource Generator) from Microsoft Visual Studio .Net 2003, = although I think you could use monoresgen.exe and mcs.exe from the = just-before-compiled mono. =20 For this purpose you should add the csc and ResGen locations to your = PATH. I added the following line to my .bashrc file. =20 PATH=3D"$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.4322" PATH=3D"$PATH:/cygdrive/c/Program Files/Microsoft Visual Studio .NET = 2003/SDK/v1.1/Bin" =20 Replace "/cygdrive/c" with the path where you have installed your copy = of MS Visual Studio. =20 After that, restart your cygwin enviroment, and type: =20 $ cd ~/src/mcs-0.29 $ make $ make install =20 All done! I hope now you have a working mono, c# compiler and class = libraries on Windows. =20 ------=_NextPart_000_0019_01C3D45C.694D76F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Building mono and mcs for=20 Windows

by=20 Giovanni Zito (gzito at mbox.thunder.it)

 

 

I=20 decided to write this guide because I found that existing instructions = weren't=20 detailed enough.

I=20 spent almost one week before I can successfull build mono on=20 Windows.

 

So=20 here are detailed steps to help = you get a working=20 version of mono 0.29 on Windows.

 

I've=20 tested it on Windows XP SP1, but it should work on Windows 2000 as=20 well.

 

 

Prepare your building = environment

1)=20 Install the .NET SDK V1.1 from=20 msdn.microsoft.com/downloads.=20 I=92ve put this step here simply because previous instructions states to = install=20 it.=20 I=92m don=92t know if and why this step is required. By the way, if you = have=20 Microsoft Visual Studio .NET 2003 installed on your system (as me), = probably you=20 can skip this step.

2)=20 Install the latest cygwin setup (about 30MB). Start choosing the = default=20 installation if you are not sure what packages you need.
You'll=20 can always get the other missing packages later, if mono configure = script will=20 require them. Be sure to get libiconv (not just libiconv2 = !).

 

3)=20 Get mono and mcs archives from

 

http://www.go-mono.com/archive/mcs-0.29.tar.gz and=20 http://www.go-mono.com/archive/mono-0.29.tar.gz<= SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10.5pt; COLOR: black; FONT-FAMILY: 'Trebuchet MS'; = mso-bidi-font-size: 10.0pt; mso-ansi-language: EN-GB; = mso-bidi-font-family: Arial">.

 

then extract=20 the tarballs in a directory of your choice. I chose to create directory = "src" in=20 my home.

 

$=20 mkdir ~/src

$=20 cd ~/src

$=20 tar xvfz = <path-where-you-downloaded-mono>/mono-0.29.tar.gz

$=20 tar xvfz = <path-where-you-downloaded-mono>/mcs-0.29.tar.gz

 

 

Get mono = dependencies

 

4)=20 Get the precompiled GLIB 2.0 and pkg-config packages (and their = dependencies) by=20 the GIMP=20 for Windows=20 project:

 

http://www.go-mono.com/archive/pkgconfig-0.11-20020310.zip<= /A>
http://www.go-mono.com/archive/glib-2.0.4-20020703.zip<= /SPAN>=20
http://www.go-mono.com/archive/glib-dev-2.0.4-20020703.zip<= /A>=20
http://www.go-mono.com/archive/libiconv-1.7.zip<= SPAN=20 lang=3DEN-GB=20 style=3D"FONT-SIZE: 10.5pt; FONT-FAMILY: 'Trebuchet MS'; = mso-bidi-font-size: 10.0pt; mso-ansi-language: EN-GB; = mso-bidi-font-family: Arial">=20
http://www.go-mono.com/archive/libiconv-dev-1.7-20020101.zip
=20
http://www.go-mono.com/archive/libintl-0.10.40-20020101.zip=

 

and=20 extract the tarballs into /usr/local.

 

The=20 /usr/local/bin directory should be in your PATH (by cygwin settings). = Also=20 ensure that /usr/local/lib is in your PATH, otherwise add the=20 line

 

 =20 PATH=3D/usr/local/lib:$PATH

 

to=20 your "~/.bashrc". After this remember to restart your cygwin envirorment = (or=20 =93source ~/.bashrc=94).

 

 

5)=20 Get the Boehm garbage collector library (libgc) from http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc6.2.tar.g= z.

 

I=20 spent many hours here. You must not build gclib with cygwin, you have to = do it=20 with cl.exe (i.e. the Microsoft compiler)!

 

Extract=20 the source tarball and then compile it using "nmake" from Visual Studio=20 .NET 2003 Command Prompt.

 

From=20 the command prompt type:

>=20 cd <path-where-you-extracted-gc>

>=20 nmake -f NT_THREADS_MAKEFILE

 

After=20 that copy Release/gc.lib and Release/gc.dll to = /usr/local/lib.

 

Also=20 you should install include files into /usr/local/include. Change to = the=20 folder where you extracted gc6.2 tarball and type:

 

mkdir=20 -p /usr/local/include

cp=20 include/gc.h /usr/local/include

cp=20 include/gc_config_macros.h /usr/local/include

cp=20 include/gc_local_alloc.h /usr/local/include

cp=20 include/gc_pthread_redirects.h /usr/local/include

cp=20 include/gc_typed.h /usr/local/include

cp=20 include/leak_detector.h /usr/local/include

 

mkdir=20 /usr/local/include/gc

cp=20 include/gc.h /usr/local/include/gc

cp=20 include/gc_alloc.h /usr/local/include/gc
cp include/gc_allocator.h=20 /usr/local/include/gc
cp include/gc_amiga_redirects.h=20 /usr/local/include/gc
cp include/gc_backptr.h = /usr/local/include/gc
cp=20 include/gc_config_macros.h /usr/local/include/gc
cp include/gc_cpp.h=20 /usr/local/include/gc
cp include/gc_gcj.h /usr/local/include/gc
cp = include/gc_inl.h /usr/local/include/gc
cp include/gc_inline.h=20 /usr/local/include/gc
cp include/gc_local_alloc.h = /usr/local/include/gc
cp=20 include/gc_mark.h /usr/local/include/gc
cp = include/gc_pthread_redirects.h=20 /usr/local/include/gc
cp include/gc_typed.h = /usr/local/include/gc
cp=20 include/leak_detector.h /usr/local/include/gc
cp = include/new_gc_alloc.h=20 /usr/local/include/gc
cp include/weakpointer.h=20 /usr/local/include/gc

 

 

6)=20 Get the ICU library from http://oss.software.ibm.com/icu/download/2.6.1/index.html

 

I=92ve=20 got icu-2.6.1-Win32_msvc7.zip, although ICU version compiled = with msvc=20 6.0 should go well.

Follow=20 the instructions below, from Bernie Solomon:

 

[=20 I have come up with a way to build using ICU under cygwin.

I = downloaded=20 the prebuilt VC6 binaries from the link on
http://oss.software.ibm.com/icu/download/2.6.1/index.html.

I=20 installed this under cygwin's structure (I used /usr/local/icu as the=20 root).

Somewhere in your path put this script as icu-config (I = chose=20 /usr/local/bin/icu-config) having edited ICU_ROOT to wherever you = installed ICU=20 (this script is attached as=20 well).

#/bin/sh

ICU_ROOT=3D/usr/local/icu
case=20 $1
in
--cppflags)
    echo=20 "-I$ICU_ROOT/include"
   =20 ;;
--ldflags)
    echo "-L$ICU_ROOT/lib -licuuc=20 -licuin"
    ;;
--version)
    = grep=20 '\<U_ICU_VERSION\>' $ICU_ROOT/include/unicode/uversion.h | sed -e=20 's/.*"\(.*\)".*/\1/'
    ;;
esac

Now you can = rerun=20 configure and this should detect the ICU installation properly and use = it.=20 ]

 

 

Important:=20 remember to "chmod u+x /usr/local/bin/icu-config" otherwise = the mono=20 configure script will be unable to detected ICU !

 

Thanks=20 to Bernie Solomon and Daniel Morgan to point me in right = direction in order=20 to successfull install ICU on cygwin

 

 

Building mono

 

You=20 are now ready to build mono.

 

$=20 cd ~src/mono-0.29
$ ./configure --with-gc=3Dboehm = CPPFLAGS=3D-I/usr/local/include=20 LDFLAGS=3D-L/usr/local/lib
$ make
$ make install

 

 

Building mcs

 

To=20 build mcs I used csc.exe (the C# compiler V7.10.3052.4) and ResGen.exe = (Resource=20 Generator) from Microsoft Visual Studio .Net 2003, although I think=20 you could use monoresgen.exe and mcs.exe from the = just-before-compiled=20 mono.

 

For=20 this purpose you should add the csc and ResGen locations to your PATH. I = added=20 the following line to my .bashrc file.

 

PATH=3D"$PATH:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.432= 2"
PATH=3D"$PATH:/cygdrive/c/Program=20 Files/Microsoft Visual Studio .NET = 2003/SDK/v1.1/Bin"

 

Replace=20 "/cygdrive/c" with the path where you have installed your copy of MS = Visual=20 Studio.

 

After=20 that, restart your cygwin enviroment, and type:

 

$=20 cd ~/src/mcs-0.29
$ make
$ make install

 

 

All=20 done! I hope now you have a working mono, c# compiler and class = libraries on=20 Windows.

 

------=_NextPart_000_0019_01C3D45C.694D76F0-- From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: runtime. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: set them for Mono. And also how do I test for the correctness of these values? EditorAttribute.EditorBaseTypeName= System.Drawing.Design.UITypeEditor, System.Drawing, Version=1.0.5000.0, Culture=neutral , PublicKeyToken=b03f5f7f11d50a3a, EditorAttribute.EditorTypeName= Microsoft.VSDesigner.Data.Design.DBParametersEditor, Microsoft .VSDesigner, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a Any pointers will be very helpful.. thanks uma From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: > It's a simple way to create files for the individual user that aren't > visible by the user (they're stored ~/.mono/isolated-storage). It > should work quite well for this, and should suffice for storing program > preferences and other related things. > > Aside from permission support and implementing a fixed-size data store > (and how should that be configured?), On the MS.NET platform this is defined in policies (caspol.exe) and by IsolatedStoragePermission. There's also a (missing?) tool, storeadm.exe, for administring IsolatedStorage. > it's pretty much feature > complete. Or mostly complete, anyway. Do you plan to complete the classes ? or to add some unit tests for them ? Thanks Sebastien Pouliot http://pages.infinit.net/ctech/poupou.html From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: We are anxious about how soon it?s going to be, because our project depends on it. The following code successfully ran under Microsoft .NET framework but caused error under Mono "ORA-01036: illegal variable name/number". Thank you in advance! CODE: OracleCommand command = new OracleCommand( "PKG_AUTH_DEV.ip_authentic2", m_dbConnection ); command.CommandType = CommandType.StoredProcedure; command.Parameters.Add( "p_login", OracleType.Char, 20 ); command.Parameters[ "p_login" ].Value = "name"; command.Parameters[ "p_login" ].Direction = ParameterDirection.Input; command.Parameters.Add( "p_password", OracleType.Char, 20 ); command.Parameters[ "p_password" ].Value = "pass"; command.Parameters[ "p_password" ].Direction = ParameterDirection.Input; command.Parameters.Add( "p_xml_config", OracleType.Clob ); command.Parameters[ "p_xml_config" ].Direction = ParameterDirection.Output; command.ExecuteNonQuery(); Friday, May 14, 2004, 3:05:16 PM, you wrote: JR> Hello Sergey, >> -----Original Message----- >> From: mono-devel-list-admin at lists.ximian.com >> [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of >> Spatar Sergey >> Sent: Friday, May 14, 2004 12:17 PM >> >> I'm interesting about when stored procedures and large objects >> (blob, clob) support will be included in System.Data.OracleClient. >> JR> What are you missing? We are working with large objects JR> for some time now. JR> Joerg. -- Best regards, Sergey Spatar From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: struct pt_regs { unsigned long gpr[32]; unsigned long nip; unsigned long msr; unsigned long orig_gpr3; /* Used for restarting system calls */ unsigned long ctr; unsigned long link; unsigned long xer; unsigned long ccr; unsigned long mq; /* 601 only (not used at present) */ /* Used on APUS to hold IPL value. */ unsigned long trap; /* Reason for being here */ unsigned long dar; /* Fault registers */ unsigned long dsisr; unsigned long result; /* Result of a system call */ }; I am at a loss on how to reconcile the code. Looking forward to the list's input. -Rico > -----Original Message----- > From: mono-devel-list-admin at lists.ximian.com > [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of > Paolo Molaro > Sent: Tuesday, May 04, 2004 10:59 AM > To: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-devel-list] Compile error Mono 0.91 on > PowerBook G4 YDL 3 > > On 05/04/04 Mikkel Kruse Johnsen wrote: > > I have a PB G4 running YDL 3 and garnome 2.5.91, ICU 2.6.2. > > > > The error is: > [...] > > exceptions-ppc.c: In function `mono_arch_handle_exception': > > exceptions-ppc.c:1082: structure has no member named `uc_regs' > > You need to poke inside /usr/include/ucontext.h and see how > the ucontext struct is defined there. It looks like on your > system it's different from mine (Debian/PPC). > Then, you either fix the function there to match, or you post > the full details of the ucontext structure on your system so > that I can fix it. > > lupus > > -- > ----------------------------------------------------------------- > lupus at debian.org debian/rules > lupus at ximian.com Monkeys do it better > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: to be a lot smaller than the MS assemblies (using the same source but different compilers) which should be a great benefit in resource constrained devices. Does this make sense? __________________________________ Do you Yahoo!? Yahoo! Domains ? Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: from the executable file." It also makes not that this is the same trick VB prior to .NET generates executables and handles it runtime. In any event, to support it wholesale would be quite a task since not all Unix environments are ELF supported or x86. I am a little interested in "native to native" though. If you are building assemblies and executibles on Linux for running on Linux there should be a way to take a shortcut just like this. Make the ELF header execute the mono IL interpeter using itself as data. It sure won't be portable non-ELF systems and I'm iffy on whether or not it will work on non-x86 ELF systems. I'm not saying to make this a mainline feature in the mcs compiler but possible slate it in as an advance platform specific feature for future versions. Tom Larsen On Fri, 18 Jun 2004, Jonathan Pryor wrote: > On Thu, 2004-06-17 at 18:20, Tom Larsen wrote: > > Don't quote me on this since I'm not a PE format guru but I believe > > at least on Windows .Net executibles pull a small feature to fake out > > the execution environment. When you run or double click on a .Net built > > exe file, the system loads the binary where the PE header tells the system > > to load a publicly exported "start" function found in mscoree.dll and > > from there on out, this is responsible for IL execution. The binary > > executible basically does a "redirect" to the IL interpter so the OS > > can't tell the difference and handles these binaries like old Win32 > > bins. > > It should be noted that this occurs only for pre-Windows XP systems. > Windows XP doesn't depend on this feature, and has a system similar to > binfmt_misc on Linux to launch .NET programs. > > > So here is the big money question: Can the mono runtime do this? > > No. Mono could do this, but only for Windows systems. Since Unix-like > systems are the primary target for Mono, it is unlikely this will be > done unless it's contributed. > > Why would this work only for Windows? File format differences. .NET > programs use the Portable Executable (PE) format, which (conveniently) > is the same format used by all Windows executables. Thus the normal OS > loader can be used, allowing the seamless integration. > > Linux, and most other Unixes, uses ELF. Mac OS X uses Mach-O. Neither > of which are similar enough to PE for the normal OS loader to think that > a PE program should be passed to the normal boot loader... ;-) > > Consequently, the same trick can't work off Windows, though it would > work for any OS that uses PE as the native program format, such as > ReactOS. > > Linux doesn't need the same trick anyway; binfmt_misc can be used for > seamless integration, though the Wine/Mono conflict can be annoying and > needs a proper solution. I would assume other Unixes have similar > features. > > - Jon > > > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: marshals strings as UTF-8. Is this still valid for Mono 1.0 ? Any updates from ECMA of supporting UTF-8 as a valid charset type ? Thanks Hemanth >>> "Hemanth Yamijala" 7/7/2004 5:24:09 PM >>> Hi, Currently, there is support in the Marshal and related classes to marshal and de-marshal strings to Unicode, Ansi or platform default encodings. Is there any chance that UTF-8 gets in this list. Or is it already supported. In some earlier messages in the newsgroup there're examples which are using the native g_utf16_to_utf8 functions for this - but as UTF-8 is a standard enough encoding, can there be more direct support for it. Do the GTK# functions which require UTF-8 strings use the native functions to achieve this functionality ? Thanks Hemanth _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: seems that the VB compiler (mbas) isn't up to compiling class assemblies just yet. Microsoft did in fact write the VB namespace in VB.NET, and uses aspects of the VB.NET language that aren't available in C#. So, in order for mono to have a complete implementation of the base class, we're either going to have to change how the C# language works slightly, write parts of the namespace in MSIL, or convert everything over and use the VB compiler when it matures. =20 However, right now it's my opinion that we should wait for the compiler to get to a point where it's usable for compiling class libraries, then start porting over the VB namespace to VB. This will help in testing the compiler as well as get the namespace in the right language. Of course, this is just my opinion, and I'd like to hear what some of the big guys have to say about it. =20 When/if work starts on the VB namespace in VB, I'm more than ready to jump in and start implementing/converting parts of it. =20 Ryan =20 =20 =20 ________________________________ From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Dennis Hayes Sent: Sunday, July 18, 2004 9:45 PM To: mono-devel-list at lists.ximian.com Subject: [Mono-devel-list] VB.NET runtime =20 Currently our VB runtime is written in C#. I have heard rumer that MS implments Microsoft.VisualBasic in VB, and that due to differences in the languages, we will need to convert this namespace to VB for complete compatablity. Is this correct? I am about to test some tools that convert between VB and C#, should I add a MS.VB.VB to CVS and start converting the code? Is this needed or useful? Dennis =20 ________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard . ------_=_NextPart_001_01C46D43.56CBD5A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dennis,

=

From the conversations we’ve = been having on the VB mailing list, it seems that the VB compiler (mbas) = isn’t up to compiling class assemblies just yet.  Microsoft did in fact = write the VB namespace in VB.NET, and uses aspects of the VB.NET language that aren’t available in C#.  So, in order for mono to have a = complete implementation of the base class, we’re either going to have to = change how the C# language works slightly, write parts of the namespace in = MSIL, or convert everything over and use the VB compiler when it = matures.

 

However, right now it’s my = opinion that we should wait for the compiler to get to a point where it’s = usable for compiling class libraries, then start porting over the VB namespace = to VB.  This will help in testing the compiler as well as get the = namespace in the right language.  Of course, this is just my opinion, and = I’d like to hear what some of the big guys have to say about = it.

 

When/if work starts on the VB = namespace in VB, I’m more than ready to jump in and start = implementing/converting parts of it.

 

Ryan

 

 

 


From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Dennis Hayes
Sent: Sunday, July 18, = 2004 9:45 PM
To: mono-devel-list at lists.ximian.com
Subject: = [Mono-devel-list] VB.NET runtime

 

Currently our VB runtime is written in C#.

I have heard rumer that MS implments Microsoft.VisualBasic in VB, and that due = to differences in the languages, we will need to convert this namespace to VB for complete = compatablity.

Is this correct?
I am about to test some tools that convert between VB and C#, should I = add a MS.VB.VB to CVS and start converting the = code?

Is this needed or useful?
Dennis

 


Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.

------_=_NextPart_001_01C46D43.56CBD5A3-- From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: seems that the VB compiler (mbas) isn't up to compiling class assemblies just yet. Microsoft did in fact write the VB namespace in VB.NET, and uses aspects of the VB.NET language that aren't available in C#. So, in order for mono to have a complete implementation of the base class, we're either going to have to change how the C# language works slightly, write parts of the namespace in MSIL, or convert everything over and use the VB compiler when it matures. However, right now it's my opinion that we should wait for the compiler to get to a point where it's usable for compiling class libraries, then start porting over the VB namespace to VB. This will help in testing the compiler as well as get the namespace in the right language. Of course, this is just my opinion, and I'd like to hear what some of the big guys have to say about it. When/if work starts on the VB namespace in VB, I'm more than ready to jump in and start implementing/converting parts of it. Ryan ________________________________ From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Dennis Hayes Sent: Sunday, July 18, 2004 9:45 PM To: mono-devel-list at lists.ximian.com Subject: [Mono-devel-list] VB.NET runtime Currently our VB runtime is written in C#. I have heard rumer that MS implments Microsoft.VisualBasic in VB, and that due to differences in the languages, we will need to convert this namespace to VB for complete compatablity. Is this correct? I am about to test some tools that convert between VB and C#, should I add a MS.VB.VB to CVS and start converting the code? Is this needed or useful? Dennis ________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard . From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: " ... The CreateChildControls method is not listed in the table because it is called whenever the ASP.NET page framework needs to create the controls tree and this method call is not limited to a specific phase in a control's lifecycle. For example, CreateChildControls can be invoked when loading a page, during data binding, or during rendering." So this is not a bug. You just have to restructure your code call sequence. HTH, Alex > The end of this email has the basic life cycle as printed out via > Response.Write methods within a page, and a control. I cannot seem to > figure out why on a Control level Postback the CreateChildControls() > method is called 3rd (which defines the HTML we'll see), while on any > other Postback its after the Page.PreRender(). This would keep any > Control Events from managing the data that needs to be printed > CreateChildControls(). > > How has anyone else dealt with this? This sure seems like a bug to me, > any opinions? Its very possible I'm just missing something, but this > seems counter-intuitive from every article on Page Life Cycle that I've > read. I have tested this on Windows/.NET and Linux/Mono and I get the > same results. My silly little test case is attached. > > Simply put, I really need a control event to change an array list that > contains controls that get added during CreateChildControls(), but this > seems impossible with the current design. > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: If you distribute a proprietary application in any way, and you are not licensing and distributing your source code under GPL, you need to purchase a commercial license of MySQL Is this really the case? If so, how does ByteFX get away with being called lgpl given that MySQL is using the GPL as the basis for their argument. What about Mono's MySql client? Chris > > From: "Luis Fernandez" > Date: 2004/09/16 Thu PM 03:08:22 EDT > To: > Subject: RE: RE: [Mono-devel-list] ByteFX development > > RE: RE: [Mono-devel-list] ByteFX developmentHi All, > > Please, correct me if I'm wrong, but I believe that the licence of the MySql > database only allows you to develop apps that are open source. If you are > intending on selling/distributing a commercial product that uses MySql as > the backend, then you are required you to purchase a comercial licence for > MySql. > > Because of this, the LGPL version of ByteFX is only of any use to open > source projects. If you want to sell a comercial product, you need to > purchase the licence, which I guess will also include their commercial > version of the GPL library that MySql provides. > > I think this might eliminate the need to develop the LGPL version if the > main intent is that it can be use in commercial applications. > > Hope I 'm wrong in my understandind of the MySql Licence but I think it's > worth checking before doing the work... > > Thanks for your great work mono developers :) > > Regards, > Luis > > > -----Original Message----- > From: mono-devel-list-admin at lists.ximian.com > [mailto:mono-devel-list-admin at lists.ximian.com]On Behalf Of Belbin, Peter > Sent: 16 September 2004 19:11 > To: 'cmorgan at alum.wpi.edu'; Belbin, Peter; 'Miguel de Icaza' > Cc: mono-devel-list at lists.ximian.com > Subject: RE: RE: [Mono-devel-list] ByteFX development > > > Yes, I agree, that is more of an issue if you are intending to sell a > product based on GPL code. > > However, I would think that you could pay them a fee and obtain the same > code under a different license > if the time came to actually making money out of it. > > > > > -----Original Message----- > From: Chris Morgan [mailto:chmorgan at charter.net] > Sent: Thursday, September 16, 2004 10:11 AM > To: Belbin, Peter; 'Miguel de Icaza' > Cc: mono-devel-list at lists.ximian.com > Subject: Re: RE: [Mono-devel-list] ByteFX development > > > If you have a look at the www.ByteFX.com and go to the data provider > > tab, you'll see there that Reggie is now part of MySQL and the ByteFX > > code is what he is developing for them. > > > > I don't see any reason why, given the work he's doing, you wouldn't > > want to stick with his code, since I understand he is making sure that > > it's mono compatible. > > > > Reggie has always been responsive to any issues that have arisen, and > > I would hope that he is just as responsive these days, even though > > he's probably got some other stuff to work on as well. > > > > Regards, > > Peter. > > > > The licensing of MySQL makes it less than appealing for commercial use. > As I mentioned in my first email, the license has changed from lgpl to gpl > meaning that any applications that use the MySQL connector become gpl'ed. > Here is the link to the connector downloads page: > > http://dev.mysql.com/downloads/connector/net/1.0.html > > Here is the GNU description of whether you can link or not: > > http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL > > Given this it seems very useful to maintain development of a lgpl MySQL > client. > > Chris > > > > > > NOTICE: This electronic mail transmission may contain confidential > information and is intended only for the person(s) named. Any use, copying > or disclosure by any other person is strictly prohibited. If you have > received this transmission in error, please notify the sender via e-mail. > > > > > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: surface.w surface.h surface.pixels etc. Hope this helps. BTW, I have updated Tao.Sdl a lot recently. Please do a checkout from CVS. I recommend looking at the unit tests for code snippets to use when marshaling pointers to structs. Dave > From: Jonathan Turner > To: mono-devel-list at lists.ximian.com > Date: Wed, 11 Aug 2004 23:08:47 -0500 > Subject: [Mono-devel-list] IntPtr and accessing structures > > Hopefully this is the correct list. I couldn't find a "mono-users" or > "mono-beginner-developers" list. > > My question's pretty straight forward. > > I'm trying to connect to SDL using the Tao.Sdl. I use: > > IntPtr mySurface = Sdl.SDL_SetVideoMode(640, 480, 16, > Sdl.SDL_SWSURFACE); > > Which gives me a window. That's great, exactly what I wanted. > > Now I want to access mySurface, but it's an IntPtr, so I can't access > any members that are SDL_Surface type members. I'm a C/C++ guy, so I > think let's cast it. > > I try something like: > > unsafe { > Sdl.SDL_Surface *mySurfaceReal = (Sdl.SDL_Surface *)mySurface.ToPointer > (); > Console.WriteLine("Surface bytes per: {0}", mySurfaceReal->pitch); > Console.WriteLine("Width: {0}", mySurfaceReal->w); > Console.WriteLine("Height: {0}", mySurfaceReal->h); > Console.WriteLine("My address for pixels: {0}", mySurfaceReal->pixels); > } > > Which doesn't work. > > Any ideas? > > I'm trying to get to the pixels member, which is a pointer to the screen > data. Once I learn how to manipulate that I'm off and running, it's > just these bits I can't seem to wrap my head around. > > Jonathan > From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: Microsoft.VisualBasic assembly grew by 7. The problem is that the source files for these tests are encoded in utf8 and CONTAIN arabic, japanese, and other international characters. As mcs no more defaults to the encoding set in the LANG environment variable (mine says LANG=en_US.UTF-8) one edits sources with, say, gedit like I do where you see every accented letter or another international character correctly represented in the source and then mcs compiles then all wrong. I regret that decision and could not find a good rationale, beyond easing source portability for VS.NET users. Even though one can change the default encoding to save source files to utf-8 (or any other encoding) in VS.NET, most users doesn't even know about that, and those who know fear to make it because you should do it before creating any file in the project, as changing encodings after creation confuses SourceSafe (their CVS/SVN counterpart). Well the remedy is to use the new -codepage:x command line option for mcs. After digging my way in the build system I added this line to the Makefile: TEST_MCS_FLAGS = -codepage:utf8 and also adjusted this one: LIB_MCS_FLAGS = /r:$(corlib) /r:System.dll /r:System.Windows.Forms.dll @Microsoft.VisualBasic.dll.resources -codepage:utf8 This email is just an alert to the many developers that commit utf-8 encoded sources, and may slip some troubling non-ASCII character into them just to find the results of compiling and executing that code aren't the expected ones. Please review your makefiles. Sorry for the ranting, Have fun, -- Rafael "Monoman" Teixeira --------------------------------------- Just the 'crazy' me in a sane world, or would it be the reverse? I dunno... From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: the same way as IIS (and other web servers) in that you app is only going to get a chance to do anything when its first request is received. Likewise global.asax only gets called when the first request is received. To get access to objects from global.asax you will need to use singletons, as you suggest, or pass them around in the Application object. hth. aaron >chicago5 at gmx.de Message: 7 Date: Sun, 7 Nov 2004 10:33:18 +0100 (MET) From: "Ulrich Staudinger" To: mono-devel-list at lists.ximian.com Subject: Re: [Mono-devel-list] xsp webservice initialization on startup Hmm.... i experimented a bit and found out that the global.asax is called after the first call to the server on any url. And iiuyc the global.asax is in fact global and i can't work on my webservice applications in the global.asax. Or do all applications inside the xsp container share the same memory, thus a static object initialized in global.asax can be accessed + used in a webservice, i.e. service.asmx? Well, that's not what i was looking for - i was looking for a way to initialize my WebService on server startup. Can you help a little more? many thanks, best regards, ulrich __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: The server is updated from the main repository every 30 minutes on the hour and half hour. Cheers, Peter From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: various groups at IBM and Bull working on open source projects for AIX - so far, Laurent Vivier and Jean Pierre Dion at Bull have been very helpful and the RPMs from gnome.bullfreeware.com make life a lot easier. From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: and we could have it working briefly. What do you think? Thanks for your help and patience, On Mon, 24 Jan 2005 17:11:49 -0800, Charlie Poole wrote: > Hi All, > > I'm back to monitoring this list - at least for messages that contain > "nunit" - and > I browsed the entire thread to try to understand the problem you're > trying to deal > with. > > For completeness, I'll list the ways to have a test not run in NUnit: > 1) Ignore it with IgnoreAttribute > 2) Ignore it at runtime with Assert.Ignore > 3) Use CategoryAttribute and exclude the category > 4) Mark it with the ExplicitAttribute > 5) Mark it with the PlatformAttribute (2.2.1 and later, I believe) > 6) Just don't run it - either put it in a separate assembly or don't > select the > namespace it lives in to be run. > 7) Use a filter. > > Items 1 and 2 turn the test yellow, the others don't. Items 3 and 4 can > be > overridden in the gui - I don't know about the gtk gui though - without > making > any changes to the code. Item 5 is for things you _never_ want to run > under > a certain platform, not for bugs you intend to fix. Item 6 seems like a > lot > of trouble if you are intending to fix something. Item 7 would be > perfect, if > we exposed a way for you to do it, but we don't. Internally, we use a > filter > to implement categories but it's intended to be generic... we just > aren't > there yet. > > So it sounds as if categories are the thing for you right now... maybe > with > some use of Platform if you have things that don't work on .NET or that > you never intend to make work on Mono. > > However, I'm not clear about why you're moving the tests elsewhere while > they are not being run. Why not just leave them in place? > > Charlie > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Rafael "Monoman" Teixeira --------------------------------------- I'm trying to become a "Rosh Gadol" before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: src. I CD'd into this directory then I got latestt code via svn for = mono, mcs and gtk-sharp. Once this was done I CD'd into the mono = directory and issued the following command: ./autogen.sh --prefix=3D/usr/local --with-preview=3Dyes This seemed to run fine. I then issued the command make get-monolite-latest This downloaded a file and seemed to pass just fine. So then I issued = the make command. After a bit of compilation it bombed out in = mono/mono/utils/mono-hash.h and mono-hash.c. It couldn't find the = glib.h header file which is located at /usr/local/glib-2.0. (I've = included the exact error file generated by make 2>error.txt) Thinking = that maybe the 1.1 unstable branch was to blame I re-issued the = ./autogen.sh command leaving off the --with-preview=3Dyes. This = resulted in the same error. I then included the path the glib.h file in = my user Include environmental varaible to no avail. Same error. Does = anyone know how I can get past this error. I had attempted to compile from source last night with the source being = on a different drive then my cygwin installation where I ran into a = different problem of the make not being able to recognize csc.exe so I = removed all source from that directory and checked out all code directly = within cygwin. I'm now getting a different problem which my compile = last night was able to get past. Any help would be greatly appreciated. Sincerely, John Sheppard Missouri Botanical Garden Life should NOT be a journey to the grave with the intention of arriving safely in an attractive and well preserved body, but rather to skid in sideways, chocolate in one hand, martini in the other, body thoroughly used up, totally worn out and screaming "WOO HOO what a ride!" ------=_NextPart_000_0036_01C50F65.078FDF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
    I hope that you = can offer me=20 some resolution. Here is my environment
 
Windows XP SP 2
uname =3D CYGWIN_NT-5.1
GLib 2.0
 
From bash shell I did a mkdir in = /usr/local for a=20 new directory name src.  I CD'd into this directory then I got = latestt code=20 via svn for mono, mcs and gtk-sharp.  Once this was done I CD'd = into the=20 mono directory and issued the following command:
 
./autogen.sh --prefix=3D/usr/local=20 --with-preview=3Dyes
 
This seemed to run fine.  I then = issued the=20 command
 
make get-monolite-latest
 
This downloaded a file and seemed to = pass just=20 fine.  So then I issued the make command.  After a bit of = compilation=20 it bombed out in mono/mono/utils/mono-hash.h and mono-hash.c.  It = couldn't=20 find the glib.h header file which is located at /usr/local/glib-2.0. = (I've=20 included the exact error file generated by make = 2>error.txt) =20 Thinking that maybe the 1.1 unstable branch was to blame I re-issued the = ./autogen.sh command leaving off the --with-preview=3Dyes.  This = resulted in=20 the same error.  I then included the path the glib.h file in my = user=20 Include environmental varaible to no avail.  Same error.  Does = anyone=20 know how I can get past this error.
 
I had attempted to compile from = source last night=20 with the source being on a different drive then my cygwin installation = where I=20 ran into a different problem of the make not being able to recognize = csc.exe so=20 I removed all source from that directory and checked out all code = directly=20 within cygwin.  I'm now getting a different problem which my = compile last=20 night was able to get past.  Any help would be greatly=20 appreciated.
 
Sincerely,
 
John Sheppard
Missouri Botanical = Garden
 
Life should NOT be a journey to the = grave with=20 the intention of
arriving safely in an attractive and well preserved = body,=20 but rather
to skid in sideways, chocolate in one hand, martini in the = other,=20 body
thoroughly used up, totally worn out and screaming "WOO HOO what = a
ride!"
------=_NextPart_000_0036_01C50F65.078FDF30-- From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: frames in a thread is to use the mono_walk_stack() function, there are a couple of examples of its use in mini/mini-exceptions.c. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From bogus@does.not.exist.com Fri Feb 8 08:55:55 2008 From: bogus@does.not.exist.com () Date: Fri, 08 Feb 2008 13:55:55 -0000 Subject: No subject Message-ID: