Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Hello, They look every bit as professional and clean as a commercial MacOS software site, but when you click the Download $COOL_APP link you get a tarball! For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. There is really nothing stopping us from building a Mono installer for applications that can be relocated, the challenges I think are: * Write the code that installs software: should this be an executable program, or should it be a package format with a special extension that a minstall command can process? * Applications that use this process should probably follow the Application Guidelines, but take things a step further: be completely relocatable and break with the Unix tradition of prefixed-based configurations. I would go as far as advocating the creation of a standard to create OSX-like bundles for Linux and encourage the various desktop efforts to include support for bundles. The first addresses software that requires it to be adapted to the target system, register itself somewhere or modify some system files; The second is for fully self contained software. A prototype should not take longer than a day. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Key Exchanges (RSA vs DH)
I'm trying to evaluate key exchange algorithms for both speed, security, and verification [S, S, V]. I was thinking of using RSA mainly, but I ran accross some info about DiffieHellman being good for key exchange. I plan on using the key exchange algorithm in exchanging keys for say... Rijndael or some other configurable algorithm. I know a bit about RSA, but not much about DH. I know for RSA the key generation process is ugly (timewise), but I can't remember how the encryption/decryption process is. It seems DH is pretty fast, but I'm unsure as to how to configure it properly for my needs [ S,S,V ]. In running a few tests, I found that the static key 'generation' works pretty good, though to me, it looks pretty unsafe. Is it? With Static key generation, I didn't need to do any passing of public key information (though it would obviously be the same w/ static key)... which leads me to believe that it's relatively pointless. Also, there's 2 lengths to specify, but I don't know what really affects what. [As an aside, a patch to rename the length's names to something more meaningful would be nice... I may make a patch when I better understand how it works] Thanks for your help, sorry about the relativly messy train of thought. -- Thomas Harning Jr. signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Miguel de Icaza wrote: For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. Well, I can see why this would be tempting for you but my advice is don't: a) You'd be rewriting what already exists, for what benefit? b) Autopackage is already being used by projects, it has small but rapidly growing mindshare - it'd be nice to have some standardisation across projects so users get a consistent experience c) Writing installers *sounds* easy, but by the time you've made it work on N^2 distros, fixed all the bugs, added digital signatures, a nice user interface, support uninstalling/upgrading native packages if they already exist etc etc, it turns out to be a lot of work. Autopackage has been in development for a long time now. It is true that a lot of this time was spent 'fixing' the design decisions of the GCC and glibc people, which I guess .NET does not suffer from, but still ... much of that time was also spent writing the bootstrap code, documentation, su/sudo wrappers, GTK+ and Qt based GUIs, integrating LZMA compression, getting professional artwork etc. * Write the code that installs software: should this be an executable program, or should it be a package format with a special extension that a minstall command can process? With autopackage it's both, but leaning more towards the former. For maxiumum ease of use, the first time you run them they'll download and install the runtime code itself. Then after that, you can just click on .package files to install them. This flexibility is why we were able to switch to a much improved compression algorithm for the 1.2 release, for instance. * Applications that use this process should probably follow the Application Guidelines, but take things a step further: be completely relocatable and break with the Unix tradition of prefixed-based configurations. Autopackages are always relocatable and we provide an easy way to install stuff to $HOME if you don't have the root password. We provide simple kits you can integrate with the program to make them relocatable, as well as complete documentation on how to do it. You can see this in action here: http://autopackage.org/flash-demo-install.html This code should be in glib really, but the independent kits are useful for now. I would go as far as advocating the creation of a standard to create OSX-like bundles for Linux and encourage the various desktop efforts to include support for bundles. This has been discussed many times on autopackage-dev, and we have invented at least three different ways of implementing appfolders on Linux. Some require integration with GNOME/KDE, and other techniques are fully backwards compatible with existing desktops. So far we've never implemented it - it turns out that basic stuff like being able to get root on a wide variety of distributions in a fully graphical way took up all our time so far. However, it was designed from scratch to support multiple user interfaces and we already have fairly complete blueprints for not only the current wizard-style UI but also an apt-get style command line UI and a MacOS X style bundle UI. The first addresses software that requires it to be adapted to the target system, register itself somewhere or modify some system files; Most software does, in my experience, even for trivial things like menu entries. A prototype should not take longer than a day. Heh, famous last words ;) The autopackage prototype only took a week, and that included uninstallation, verification and dependency checking. Turning it into a product took three years. There's no need to re-invent the wheel here. thanks -mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
We already have a for all distros installer (that uses bitrock). But it'd be really cool to see this use autopackage. Yes, I saw. Bitrock is a good product. My main aim here is to get Mono applications themselves using graphical installers - if the Mono runtime itself is also autopackaged and so can be depsolved in then great, but if not then there's still benefit. I think the best way to start would be from the top down. It'd be nice to do a package of MonoDevelop and then see what can be made easier to do with helpers in autopackage, etc. Agreed. From what I know of Mono the following things might be an issue: * DLL mappings * the GAC * Ahead of time compilation * Detecting assembly versions (we use a variety of ugly hacks to get ELF DSO versions) But there's only one way to find out, and that's to go ahead and do it. I'd love to but right now, can't ... so hopefully somebody will decide to have a go. thanks -mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: problems with Syscall.syslog fot mono-1.1.8.3
On Thu, 2005-07-28 at 13:37 +0400, Vorobiev Maksim wrote: Today I've upgraded mono version to 1.1.8.3 and found, that it has no fixes for syslog support. Not in sources, not in binaries. That version will contain these changes? Those changes were made to svn-trunk, not the 1.1.8 branch, so they'll appear in 1.1.9. Alternatively, if a 1.1.8.4 will be released, I could backport the patches from head to 1.1.8... - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Source code file name and line form PDB
Hi, It could be very good if Mono could read PDB files because it could help debugging code on Mono compiled by MS compilers. As I know the only reason is that noone implemented it yet. Are there any known legal or other issues regarding PDB files? Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Patch for System.DirectoryServices - kerberos support for TARGET_JVM
Hello all,
Attached is a proposed patch for kerberos authentication support in
TARGET_JVM.
Most of the implementation resides in .jvm directory or under ifdef
TARGET_JVM, also I have changed Bind api a bit so it can receive
AuthenticationTypes as an additional parameter.
Boris
--
Boris Kirzner
Mono RD team, Mainsoft Corporation.
Blogging at http://boriskirzner.blogspot.com/
Index: Novell.Directory.Ldap/Connection.cs
===
--- Novell.Directory.Ldap/Connection.cs (revision 47755)
+++ Novell.Directory.Ldap/Connection.cs (working copy)
@@ -1207,6 +1207,25 @@
}
///TLS not supported in first release
+ internal Stream InputStream
+ {
+ get { return in_Renamed; }
+ }
+
+ internal Stream OutputStream
+ {
+ get { return out_Renamed; }
+ }
+
+ internal void ReplaceStreams(Stream newIn, Stream newOut)
+ {
+ // wait for reader to stop, see LdapConnection.Bind
+ waitForReader(null);
+ in_Renamed = newIn;
+ out_Renamed = newOut;
+ startReader();
+ }
+
public class ReaderThread
{
private void InitBlock(Connection enclosingInstance)
Index: Novell.Directory.Ldap/LdapConnection.cs
===
--- Novell.Directory.Ldap/LdapConnection.cs (revision 47755)
+++ Novell.Directory.Ldap/LdapConnection.cs (working copy)
@@ -36,6 +36,15 @@
using Novell.Directory.Ldap.Utilclass;
#if !TARGET_JVM
using Mono.Security.Protocol.Tls;
+#else
+using org.ietf.jgss;
+using javax.security.auth;
+using javax.security.auth.login;
+using java.security;
+
+using Novell.Directory.Ldap.Security;
+using System.Collections.Specialized;
+using System.Configuration;
#endif
using System.Security.Cryptography.X509Certificates;
@@ -471,6 +480,9 @@
private static System.Object nameLock; // protect agentNum
private static int lConnNum = 0; // Debug, LdapConnection number
private System.String name; // String name for debug
+
+ private const string LDAP_SECURITY_MECH =
System.DirectoryServices.SecurityMech;
+ private const string LDAP_SECURITY_APP_NAME =
System.DirectoryServices.SecurityAppName;
/// summary Used with search to specify that the scope of
entrys to search is to
/// search only the base obect.
@@ -1172,10 +1184,24 @@
/// /exception
public virtual void Bind(System.String dn, System.String
passwd)
{
- Bind(Ldap_V3, dn, passwd, defSearchCons);
+ Bind(dn, passwd, AuthenticationTypes.None);
return ;
}
+ public virtual void Bind(System.String dn, System.String
passwd, AuthenticationTypes authenticationTypes)
+ {
+#if TARGET_JVM
+ if (authenticationTypes != AuthenticationTypes.None
+ authenticationTypes !=
AuthenticationTypes.ServerBind
+ authenticationTypes !=
AuthenticationTypes.Anonymous)
+ BindSecure(dn, passwd, authenticationTypes);
+ else
+#endif
+ Bind(Ldap_V3, dn, passwd, defSearchCons);
+
+ return ;
+ }
+
/// summary Synchronously authenticates to the Ldap server
(that the object is
/// currently connected to) using the specified name, password,
/// and Ldap version.
@@ -1388,7 +1414,7 @@
[CLSCompliantAttribute(false)]
public virtual void Bind(int version, System.String dn,
sbyte[] passwd, LdapConstraints cons)
{
- LdapResponseQueue queue = Bind(version, dn, passwd,
null, cons);
+ LdapResponseQueue queue = Bind(version, dn, passwd,
null, cons, null);
LdapResponse res = (LdapResponse) queue.getResponse();
if (res != null)
{
@@ -1440,7 +1466,7 @@
[CLSCompliantAttribute(false)]
public virtual LdapResponseQueue Bind(int version,
System.String dn, sbyte[] passwd, LdapResponseQueue queue)
{
- return Bind(version, dn, passwd, queue, defSearchCons);
+ return Bind(version, dn, passwd, queue, defSearchCons,
null);
}
/// summary Asynchronously authenticates to the Ldap
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi, I attached a patch file that replaces all 2.0.3600.0 to 2.0.0.0 and 8.0.3600.0 to 8.0.0.0 where they are used to set versions of an assembly or reference an assembly. I did not add any ChangeLog entries. If we want to provide so much ChangeLog some automated tool should be used. Kornél - Original Message - From: Miguel de Icaza To: Kornél Pál Sent: Thursday, July 28, 2005 8:18 AM Subject: Re: [Mono-devel-list] Profile 2.0 assembly versions Hello, I filed http://bugzilla.ximian.com/show_bug.cgi?id=75646. I don't try to propose a patch file because I'm sure it would be rejected. Having a patch would be great. Miguel. AssemblyVersion20.tar.gz Description: GNU Zip compressed data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Imho it would be a good idea to fix all those attributes in System.Web first to use the Consts - Scheme before having to change all that stuff twice. mfg Andreas - Original Message - From: Kornél Pál [EMAIL PROTECTED] To: Miguel de Icaza [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Thursday, July 28, 2005 2:25 PM Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions Hi, I attached a patch file that replaces all 2.0.3600.0 to 2.0.0.0 and 8.0.3600.0 to 8.0.0.0 where they are used to set versions of an assembly or reference an assembly. I did not add any ChangeLog entries. If we want to provide so much ChangeLog some automated tool should be used. Kornél - Original Message - From: Miguel de Icaza To: Kornél Pál Sent: Thursday, July 28, 2005 8:18 AM Subject: Re: [Mono-devel-list] Profile 2.0 assembly versions Hello, I filed http://bugzilla.ximian.com/show_bug.cgi?id=75646. I don't try to propose a patch file because I'm sure it would be rejected. Having a patch would be great. Miguel. ___ 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-devel-list] mono use 100% cpu when not use root
I use SuSE Linux 9.3 (x86-64) out of the box... Is there something that I can do to solve the problem? 2005/7/28, Miguel de Icaza [EMAIL PROTECTED]: Hello, You could try stracing the process and see what its doing, or attaching with gdb and getting a stack trace of all threads (t a a bt) Miguel I attached the result. I have upgraded to 1.1.8.3 and I have also tried to compile from source but I'm not able to compile if I am not root. When copiled by root, from normal user I have thesame problem. Ah, something in your libc is making Mono hang. This seems to be very specific to your distro. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Calling Native C api - Marshalling issue.
I am getting problem while executing the c library function from C#.
Following is the equivalent code .
C Code :
---
//This is the structure in C
typedef struct MyDataType
{
u_intdata1;
u_int data2;
} MyData;
//This is the C function which is called by passing pointer to above
structure
function u_int DoSomeOperation(MyData* pData)
{
return pData-data1 +pData-data2;
}
C# Code :
Following code shows how I am executing that call.
using System;
using System.Runtime.InteropServices;
namespace Test
{
//Define equivalent class to MyData structure
[StructLayout(LayoutKind.Sequential)]
public class CSMyData
{
public UInt32 data1;
public UInt32 data2;
}
public class Test
{
//Import the dll and define C function.
[DllImport (mylibrary.dll, EntryPoint=DoSomeOperation)]
static extern Int32 OperateData( ref CSMyData pData);
//Other way of defining
//static extern Int32 OperateData( [In,Out] CSMyData pData);
//main function for console application
static void Main()
{
UInt32 result = 0;
CSMyData inData = new CSMyData();
inData.data1 = 0x;
inData.data2 = 0xFF;
result = OperateData(ref inData);
Console.WriteLine( Addition = result.ToString();
}
}
}
Issue:
When I am printing value in the C code side ,ie in DoSomeOperation
function , the values are corrupted.
Please let me know what part is wrong.
regards,
Yogi
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] PEAPI and 1.1.8.3 build
Hi, Gary M. Smithrud wrote: I'm attempting to build 1.1.8.3 on Solaris (if anyone has any experience doing this and has suggestions, let me know) and it fails because it is attempting to build PEAPI, which is not part of the tarball. Is this needed? I'm not sure whether I should comment it out of the makefile or attempt to get it from one of the branches (main?). Thanks! PEAPI is part of the tarball. Check if your tar command works fine. (i.e. try GNU tar instead of the pre-installed one.) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PEAPI and 1.1.8.3 build
That's it! Thanks! Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 10:38 AM To: Gary M. Smithrud Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-devel-list] PEAPI and 1.1.8.3 build Hi, Gary M. Smithrud wrote: I'm attempting to build 1.1.8.3 on Solaris (if anyone has any experience doing this and has suggestions, let me know) and it fails because it is attempting to build PEAPI, which is not part of the tarball. Is this needed? I'm not sure whether I should comment it out of the makefile or attempt to get it from one of the branches (main?). Thanks! PEAPI is part of the tarball. Check if your tar command works fine. (i.e. try GNU tar instead of the pre-installed one.) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Calling Native C api - Marshalling issue.
Hi,
classes are by default passed by-ref to unmanaged code, i.e. a pointer to the
data is passed to the C side. If you define your managed method as 'ref', then
the unmanaged code will receive a pointer-to-a-pointer to the data. Try
removing the 'ref', or defining CSMyData as a struct, which by default
marshalled
by-value.
Zoltan
On 7/28/05, Yogendra Thakur [EMAIL PROTECTED] wrote:
I am getting problem while executing the c library function from C#.
Following is the equivalent code .
C Code :
---
//This is the structure in C
typedef struct MyDataType
{
u_intdata1;
u_int data2;
} MyData;
//This is the C function which is called by passing pointer to above
structure
function u_int DoSomeOperation(MyData* pData)
{
return pData-data1 +pData-data2;
}
C# Code :
Following code shows how I am executing that call.
using System;
using System.Runtime.InteropServices;
namespace Test
{
//Define equivalent class to MyData structure
[StructLayout(LayoutKind.Sequential)]
public class CSMyData
{
public UInt32 data1;
public UInt32 data2;
}
public class Test
{
//Import the dll and define C function.
[DllImport (mylibrary.dll, EntryPoint=DoSomeOperation)]
static extern Int32 OperateData( ref CSMyData pData);
//Other way of defining
//static extern Int32 OperateData( [In,Out] CSMyData pData);
//main function for console application
static void Main()
{
UInt32 result = 0;
CSMyData inData = new CSMyData();
inData.data1 = 0x;
inData.data2 = 0xFF;
result = OperateData(ref inData);
Console.WriteLine( Addition = result.ToString();
}
}
}
Issue:
When I am printing value in the C code side ,ie in DoSomeOperation
function , the values are corrupted.
Please let me know what part is wrong.
regards,
Yogi
___
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-devel-list] mono use 100% cpu when not use root
Hi, Also, could you try renaming your $HOME/.wapi directory to something else and trying again ? Zoltan On 7/28/05, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I use SuSE Linux 9.3 (x86-64) out of the box... Is there something that I can do to solve the problem? How did you install Mono, from our packages, or from your source? If you did it from source, could you post your config.h and configure log files? Miguel ___ 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-devel-list] TimeStamp support on oracle...
I really need the new TimeStamp type (supported starting from oracle 9). It's
a MS.NET supported type (i've made tests)...
I've begin to do a little patch (attached) to add the timestamp type to
oracle.client...
but... I've a strange error when i try to do a Fill, it failed with:
Unhandled Exception: System.Data.OracleClient.OracleException:
in 0x0013d System.Data.OracleClient.Oci.OciStatementHandle:Fetch ()
in 0x0002c System.Data.OracleClient.OracleDataReader:Read ()
in 0x002f4 System.Data.Common.DbDataAdapter:FillTable (System.Data.DataTable
dataTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords,
System.Int32 counter)
in 0x0011f System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, System.String srcTable, IDataReader dataReader, Int32 startRecord,
Int32 maxRecords)
in 0x000d5 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, Int32 startRecord, Int32 maxRecords, System.String srcTable,
IDbCommand command, CommandBehavior behavior)
in 0x00044 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet)
in 0x007b8 ConsoleIntranet.Class1:TestTimestamp ()
in 0x00015 ConsoleIntranet.Class1:Main (System.String[] args)
Could someone help me how to resolve this issue?
thanks
___
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce
message non conforme à sa destination, toute diffusion ou publication, totale
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce
message n'est pas assurée et la société émettrice ne peut être tenue pour
responsable de son contenu.
Index: mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
===
--- mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs (revision 47807)
+++ mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs (working copy)
@@ -258,7 +258,7 @@
OciDataType bindType = ociType;
IntPtr bindValue = IntPtr.Zero;
int rsize = 0;
-
+ Console.WriteLine(Parametre : +ociType.ToString());
// TODO: handle InputOutput and Return parameters
if (direction == ParameterDirection.Output) {
// TODO: need to figure out how OracleParameter
@@ -324,9 +324,11 @@
bindSize = 0;
}
else {
+ Console.WriteLine(OracleType +oracleType.ToString());
// TODO: do other data types and oracle data types
// should I be using IConvertible to convert?
if (oracleType == OracleType.DateTime) {
+ Console.WriteLine(DATE!!!);
string oraDateFormat = connection.GetSessionDateFormat ();
string sysDateFormat = OracleDateTime.ConvertOracleDateFormatToSystemDateTime (oraDateFormat);
@@ -637,8 +639,11 @@
dbType = DbType.AnsiStringFixedLength;
ociType = OciDataType.Char;
break;
+ case OracleType.Timestamp:
+ dbType = DbType.DateTime;
+ ociType = OciDataType.TimeStamp;
+ break;
case OracleType.DateTime:
- case OracleType.Timestamp:
case OracleType.TimestampLocal:
case OracleType.TimestampWithTZ:
dbType = DbType.DateTime;
Index: mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataType.cs
===
--- mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataType.cs (revision 47807)
+++ mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataType.cs (working copy)
@@ -43,6 +43,7 @@
Blob = 0x71,
BFile = 0x72,
OciString = 0x9b,
- OciDate = 0x9c
+ OciDate = 0x9c,
+ TimeStamp = 0xbb
}
}
Index: mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParameterDescriptor.cs
===
--- mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParameterDescriptor.cs (revision
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Hello, For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. Well, I can see why this would be tempting for you but my advice is don't: a) You'd be rewriting what already exists, for what benefit? Raise the bar in the state of art of Linux installation. b) Autopackage is already being used by projects, it has small but rapidly growing mindshare - it'd be nice to have some standardisation across projects so users get a consistent experience Am thinking of something that normal users can use, not something that copes with every possible angle of software dependencies, but going for a simple OSX-like setup. c) Writing installers *sounds* easy, but by the time you've made it work on N^2 distros, fixed all the bugs, added digital signatures, a nice user interface, support uninstalling/upgrading native packages if they already exist etc etc, it turns out to be a lot of work. Well, Ximian's business was largely managing software installation and all of its related angles as part of its red carpet product, so am not terrified by this. Certainly doing a general purpose tool for all kinds of software (native c, dependencies, mix of code) is needed, and I think autopackage fits nicely in this area. What am suggesting is something Mono-specific for small applications that can take care of average applications being developed. Think about Perl, Ruby and Python's frameworks for doing software installation: they are not frameworks for doing *everything* but they can do a pretty good job for *most* of their software. Autopackages are always relocatable and we provide an easy way to install stuff to $HOME if you don't have the root password. We provide simple kits you can integrate with the program to make them relocatable, as well as complete documentation on how to do it. Such a document would be invaluable. My feeling is that autopackage focus is in adapting existing software which is prefix-designed to be relocatable. Where can I find the documents/tutorials for this? We might want to change Mono's installer to use something like this, as it currently breaks for 2.x uses. What I would like to do is break with the prefix tradition. So far we've never implemented it - it turns out that basic stuff like being able to get root on a wide variety of distributions in a fully graphical way took up all our time so far. However, it was designed from scratch to support multiple user interfaces and we already have fairly complete blueprints for not only the current wizard-style UI but also an apt-get style command line UI and a MacOS X style bundle UI. What I care about the most with bundles is being compatible with OSX in as much as possible. Am talking about the file system structure, not really the actual dmg image, ie Chess.app. The advantage of this is that we could distribute cross-platform bundles that would work on OSX and Linux. The dmg problem would be handled by a mime-type handler, so am not too worried about that. Most software does, in my experience, even for trivial things like menu entries. Yeah, this might have to live in a Mono.InstallationServices dll. The autopackage prototype only took a week, and that included uninstallation, verification and dependency checking. Turning it into a product took three years. There's no need to re-invent the wheel here. Yeah, but like I said, autopackage is for seriously complicated apps; Am thinking it more for pure Mono apps which have much less dependencies and we can safely assume `Mono is in your path' Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
a) You'd be rewriting what already exists, for what benefit? Raise the bar in the state of art of Linux installation. That's certainly a worthy goal, but I'd like to think we already did - easy to use one click installs are something we put a lot of effort into. If you haven't watched the Flash demo, I'd recommend it: http://autopackage.org/flash-demo-install.html Am thinking of something that normal users can use, not something that copes with every possible angle of software dependencies, but going for a simple OSX-like setup. Well, it's not drag/drop, but it *is* just as simple: * Click on a link in a webpage * Click Open in the firefox file download dialog (actually you can tell firefox to always open this filetype) * It downloads ... there is a simple confirmation window: http://autopackage.org/screenshots/newshots/gtkfe-intro.png * You click Install and then enter your password (or not): http://autopackage.org/screenshots/newshots/autosu-ask.png * That's it. You get a summary screen at the end: http://autopackage.org/screenshots/newshots/gtk-yaydone.png The user doesn't have to think about dependencies, or install paths, or anything really - the only decision to make is Do I know the root password and this is easy, either you do or you don't. On MacOS X you must make some more decisions: * Do I click the app right now, while it's inside the DMG? * Or ... do I drag it to the dock? * Or ... the /Applications directory? Actually only the last one is correct, but that's something you just have to know. So I don't think the autopackage UI is complicated. What am suggesting is something Mono-specific for small applications that can take care of average applications being developed. Think about Perl, Ruby and Python's frameworks for doing software installation: they are not frameworks for doing *everything* but they can do a pretty good job for *most* of their software. Sure, but your typical Mono app does have dependencies: the Foo# library bindings if nothing else. Well, you could ship them all as part of the Mono platform and that'd work, but bleeding edge apps would still have problems. A large platform combined with automatic graphical dep resolution for very new libraries: http://autopackage.org/screenshots/newshots/gtkfe-retreive.png seems like a nice balance. Such a document would be invaluable. My feeling is that autopackage focus is in adapting existing software which is prefix-designed to be relocatable. Sure, we try and make this easy because autopackages are relocatable as a rule. But that's just an artifact of most C programs not being so, there's nothing C specific about it. Where can I find the documents/tutorials for this? We might want to change Mono's installer to use something like this, as it currently breaks for 2.x uses. Actually, this document is for an older version: http://autopackage.org/docs/binreloc/ The CVS version of binreloc is simplified considerably and can generate different styles of code (eg, raw C vs glib style). It also has less bizarre memory management semantics. Unfortunately it's not documented yet, but the basic theory is the same: provide convenience functions for finding your own path, getting the prefix from it, and then appending other paths (all in one function if you like). What I would like to do is break with the prefix tradition. Yes, me also. That's why we have it as a rule. What I care about the most with bundles is being compatible with OSX in as much as possible. Am talking about the file system structure, not really the actual dmg image, ie Chess.app. Given that bundles need to be customised anyway, for instance to have Aqua compatible artwork, I'm not sure it's worth trying to make Linux apps the same right now. It'd be better to provide an installer EXE for Windows, an autopackage for Linux and an bundle for MacOS X. The dmg problem would be handled by a mime-type handler, so am not too worried about that. Right. But MIME type handler for GNOME 2.10? or GNOME 2.8? Or KDE 3.x? Or all of them? Yeah, but like I said, autopackage is for seriously complicated apps; Am thinking it more for pure Mono apps which have much less dependencies and we can safely assume `Mono is in your path' Well, not really, right now autopackage is used for really quite simple apps packaging-wise: Gaim, Inkscape, AbiWord: none of them are too terrible. I tell you what. How about I try and package a Mono app tonight, and I will show you how trivial it really is. There's a quickstart document here: http://autopackage.org/developer-quickstart.html which shows you all the basics in one page, and it also covers basic advice like don't depend on CVS versions of unstable libraries ;) Ignore the C++ warning, this is relevant only for the stable 1.0.x series, but we have much improved C++ support in CVS that will make dealing with the ABI change fully automatic. I
RE: [Mono-devel-list] Calling Native C api - Marshalling issue.
Thanks Massi Zoltan.
It works after removing the ref. As Zoltan said, by defualt classed are
passed as reference to unmanaged code.
-YoGi
-Original Message-
From: Massimiliano Mantione
To: Yogendra Thakur
Cc: 'mono-devel-list@lists.ximian.com '
Sent: 7/28/05 11:17 AM
Subject: Re: [Mono-devel-list] Calling Native C api - Marshalling issue.
On Thu, 2005-07-28 at 10:15 -0400, Yogendra Thakur wrote:
I am getting problem while executing the c library function from C#.
//Define equivalent class to MyData structure
[StructLayout(LayoutKind.Sequential)]
public class CSMyData
{
either should be a struct, not a class...
//Import the dll and define C function.
[DllImport (mylibrary.dll, EntryPoint=DoSomeOperation)]
static extern Int32 OperateData( ref CSMyData pData);
//Other way of defining
//static extern Int32 OperateData( [In,Out] CSMyData pData);
...or you should omit the ref (or the [In,Out]).
With these modification it works.
The issue is that if CSMyData is a struct, then the ref (or the
[In,Out]) is needed to get the address of the struct.
But if CSMyData is a class, marshalling converts it correctly.
I am no marshalling expert, but I think that if you put the ref
you pass the address of the object reference :-)
Ciao,
Massi
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Npgsql breaks multi-line queries
Hi! I found that Npgsql client breaks multi-line queries by removing newline characters. This leads to improper sql being sent do postgresql. The following CommandText select a as b from C is sent as select a as bfrom C which is obviously an error because the space between b and from is missing. This is because RegExp used to filter parameters doesn't use RegexOptions.Singleline option. I'm attaching a patch against SVN trunk which fixes the problem. Would anyone care to apply it? -- Jaroslaw Kowalski http://blog.jkowalski.net/ http://nlog.sourceforge.net/ npgsql.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mod_mono / XSP compiled from scratch latest
Hello, Corlib not in sync with this runtime: expected corlib version 37, found 22. Download a newer corlib or a newer runtime at http://www.go-mono.com/daily. This is not an xsp/mod_mono issue. You updated Mono incorrectly or you have two monos installed. I’m not exactly sure what it is talking about since all my tarballs were at the latest version when I compiled them. Can anyone help me out here? Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Source code file name and line form PDB
On 07/28/05 Kornél Pál wrote: As I know the only reason is that noone implemented it yet. And the real reason noone even started implementing it is that the pdb file format is not documented. The MS people responsible for it don't even let other MS programmers access the file format (for the official reason that they may want to change the implementation, but the likely reason is the same as for large part of proprietary sw: it either infringes on someone else work or it is crap:-). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Npgsql breaks multi-line queries
I've forwarded your patch to Francisco Jr. that created/maintains npgsql, as the primary repository for it is at gborg under his control, and is just synced inside Mono's. Thanks for spotting that, :) On 7/28/05, Jaroslaw Kowalski [EMAIL PROTECTED] wrote: Hi! I found that Npgsql client breaks multi-line queries by removing newline characters. This leads to improper sql being sent do postgresql. The following CommandText select a as b from C is sent as select a as bfrom C which is obviously an error because the space between b and from is missing. This is because RegExp used to filter parameters doesn't use RegexOptions.Singleline option. I'm attaching a patch against SVN trunk which fixes the problem. Would anyone care to apply it? -- Jaroslaw Kowalski http://blog.jkowalski.net/ http://nlog.sourceforge.net/ ___ Mono-devel-list mailing list Mono-devel-list@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. It hurts! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] monodevelop-GtkSourceView-CRITICAL
Hello, i am a new mono programmer, i buy Mono-a developer's notebook of O Reilly and i am studing it. I have installed on my linux slackware notebook the latest version of mono but when i run monodevelop i have this error: (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 681 (gtk_source_buffer_new_with_language): assertion `GTK_IS_SOURCE_LANGUAGE (language)' failed (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 1470 (gtk_source_buffer_set_highlight): assertion `GTK_IS_SOURCE_BUFFER (buffer)' failed i have found on google this link http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=PROJECT;action=display;num=1116846330 and i try to delete ./config/Monodevelop but i have always this problem :-( please help me :-) thank's Stefano Somaglia -- Stefano Somaglia http://www.suma.it Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in questo messaggio e negli eventuali files allegati sono riservate e ad uso esclusivo del destinatario, per le finalità indicate nel messaggio stesso. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo dal Suo sistema, senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us. Thank ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
On 7/28/05, Rodrigo B. de Oliveira [EMAIL PROTECTED] wrote: ... I'm getting off-by-one errors only with raise/throw statements: The behavior is actually a little more complex but still predictable. The stack trace entry for the raise line is always the line of the next statement in the same method: src name=other.boo def foo(): raise foo return 1 def bar(): foo() bar() /src I get then: Unhandled Exception: System.ApplicationException: foo in [0xa] (at Other.boo:5) OtherModule:foo () in [0x0] (at Other.boo:8) OtherModule:bar () in [0x0] (at Other.boo:10) OtherModule:Main (System.String[] argv) Any ideas? bamboo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [off topic] mono/.net pure managed wrapperlibraries
Don't think about performance on this one, because the loss will be absolutely unmeasurable (or at least extremely small) unless you want to stream byte by byte. It is quite possible, that the mono jit will inline that code anyways... Just create an abstract base class (or interface) and then inherit and you're done. Andreas - Original Message - From: Dominik Pich [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, July 28, 2005 7:32 PM Subject: [Mono-devel-list] [off topic] mono/.net pure managed wrapperlibraries Ok, I'm aware this is offtopic but hey :) it is _RELATED_ to mono in so far that I think about using it :P So... my situation: I have managed code written using ms .NET which uses MS managed wrapper for WMP. I'd like to port that code to osx using mono and as I then dont have WMP but QuickTime, I thought I'd write a wrapper that on WINDOWS uses WMP and on OSX uses QuickTime. So far so good... ;) Instead of: on Windows I got:MyApp - managed WMP - WMP on OSX I got:MyApp - managed QuickTime - QuickTime I add the add. 'wrapper layer' so I have a common API: on Win/osx: MyApp - managed Media Player - managed WMP (win) - WMP - managed QuickTime (osx) - Quicktime Now Im thinking about the performance decrease of such an add. 'wrapper layer' and wonder if I could 'inline' it ... so I dont have the wrapper in the compiled code: I write: oMediaPlayer-play(); and it compiles to either QTplayer-play() WMPplayer-play() ... or do I worry to much? Thanks, Dominik ___ 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-devel-list] [PATCH] Profile 2.0 assembly versions
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do do
it now instead of doing it twice (and adding lots of changelog entries
twice).
Andreas
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Thursday, July 28, 2005 4:11 PM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
Note that I found 2:0:3600:0 in test-377-net_2_0-il.il so I canged it as
well to 2:0:0:0. I found {2,0,3600,0}and {8,0,3600,0}in domain.c I changed
them as well. I think there are no more x.0.3600.0 versions anywhere
because
this time I searched for 3600. Updated patch attached.
Could you please be more specific because I do not understand why it is
required. I was able to compile a clean checkout (mcs and mono) with the
patch applied without errors.
Are Consts.cs files automatically generated (I don't think so) or what is
the problem?
If the problem is the size of the diff file I can't help you. If you want
please feel free to separate it to as many files as you want but I don't
want do it.
Kornél
- Original Message -
From: Andreas Nahr [EMAIL PROTECTED]
To: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Thursday, July 28, 2005 2:40 PM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Imho it would be a good idea to fix all those attributes in System.Web
first
to use the Consts - Scheme before having to change all that stuff twice.
mfg
Andreas
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Miguel de Icaza [EMAIL PROTECTED];
mono-devel-list@lists.ximian.com
Sent: Thursday, July 28, 2005 2:25 PM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
I attached a patch file that replaces all 2.0.3600.0 to 2.0.0.0 and
8.0.3600.0 to 8.0.0.0 where they are used to set versions of an
assembly
or
reference an assembly.
I did not add any ChangeLog entries. If we want to provide so much
ChangeLog
some automated tool should be used.
Kornél
- Original Message -
From: Miguel de Icaza
To: Kornél Pál
Sent: Thursday, July 28, 2005 8:18 AM
Subject: Re: [Mono-devel-list] Profile 2.0 assembly versions
Hello,
I filed http://bugzilla.ximian.com/show_bug.cgi?id=75646.
I don't try to propose a patch file because I'm sure it would be
rejected.
Having a patch would be great.
Miguel.
___
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-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-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
I agree with you that this a better idea but I will never try to submit such
a big patch for proposal because it would change too much code and it
figured out that it is nearly impossible to make any major change to Mono
because if there are no mistakes and errors in the patch itself an endless
list can be created about things that should be done before the patch can be
comitted altought they don't block the patch in fact.
I see a lot of things in Mono that sould be made more reliable using some
centralization but I don't want to create n+1 wariants of this patch.
I reported the problem, I proposed a patch, the patch seems to be correct
(because no notices were provided regarding the patch itself). If you want
to do hundreds of things that are not required to apply the patch before
applying the patch it's up to you but I don't want to solve all the problems
you can imagine just to commit this patch.
Anyway I think having different verion numbers than MS.NET is a more
critical issue than having a weakly centralized assembly referencing
practice.
Note that the references in System.Web.UI.WebControls are in NET_2_0 only
code blocks and these references are not in other versions. This seems to be
consistent practice in System.Web.UI.WebControls. Centralizing the assembly
reference could save some disk space but currently it is not required. It
will be required when a new (post 2.0) .NET Framework version will be
released but currently even 2.0 was not released yet so it will be in the
distant future.
Kornél
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
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-devel-list] [PATCH] Profile 2.0 assembly versions
Yes - it would make a lot of sense to put them into a single file. However
it would come at a cost of up to 2kb of size added to EACH assembly that
uses Consts.
In fact I think we could do something really clever to our compiler here,
that would also benefit for a lot of other cases.
AFAIK the compiler can already eliminate dead code. I would propose a step
that allows the compiler to scan for dead code again AFTER constants are
resolved. This way the compiler would be able to completely eliminate the
Consts Class after compiling. This would also add lots of added value to
other applications. It's quite common to use private consts and especially
enums to structure the code and make it more readable. With the proposed
compiler function all of these things could be thrown out at compile-time,
which could help a lot of applications to get smaller.
We could add a compiler-switch for that like -EliminatePrivateConstants
Andreas
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
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-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
Bens idea is good. There should be a single file to define versions.
Then the assembly references could be in the Consts.cs files of each
assembly but there were no #if clauses to specify version because the
reference constants could use the version constants defined in the common
file.
BTW is there a way to have a common .sources file because it seems that we
are going to have more and more common files that has to be added to the
.sources file of each assembly?
Kornél
- Original Message -
From: Andreas Nahr [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:42 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Yes - it would make a lot of sense to put them into a single file. However
it would come at a cost of up to 2kb of size added to EACH assembly that
uses Consts.
In fact I think we could do something really clever to our compiler here,
that would also benefit for a lot of other cases.
AFAIK the compiler can already eliminate dead code. I would propose a step
that allows the compiler to scan for dead code again AFTER constants are
resolved. This way the compiler would be able to completely eliminate the
Consts Class after compiling. This would also add lots of added value to
other applications. It's quite common to use private consts and especially
enums to structure the code and make it more readable. With the proposed
compiler function all of these things could be thrown out at compile-time,
which could help a lot of applications to get smaller.
We could add a compiler-switch for that like -EliminatePrivateConstants
Andreas
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:42 +0200, Andreas Nahr wrote: Yes - it would make a lot of sense to put them into a single file. However it would come at a cost of up to 2kb of size added to EACH assembly that uses Consts. Maybe the *FILE* will be 2 kb, but the metadata added probably won't be. To add a class with a single const we'd need to add: 1) a entry in the classes table 2) an entry in the fields table 3) a constant string in the strings heap. At runtime, the only datastructure that will ever be allocated due to this class is the hashtable that goes from Namespace/Class - class field. I'm not even sure if that gets created for private classes, I'd have to dig into the code. The fields and string heap data gets loaded lazily on the first access. In fact I think we could do something really clever to our compiler here, that would also benefit for a lot of other cases. AFAIK the compiler can already eliminate dead code. I would propose a step that allows the compiler to scan for dead code again AFTER constants are resolved. This way the compiler would be able to completely eliminate the Consts Class after compiling. This would also add lots of added value to other applications. It's quite common to use private consts and especially enums to structure the code and make it more readable. With the proposed compiler function all of these things could be thrown out at compile-time, which could help a lot of applications to get smaller. A cecil based il-to-il optimizer could do that in the future. Of course, if you really want to look at how can we make teh metadata smaller we could do a simple obfuscator -- we could rename private / internal methods/classes to have small names, etc. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:57 +0200, Kornél Pál wrote: BTW is there a way to have a common .sources file because it seems that we are going to have more and more common files that has to be added to the .sources file of each assembly? I think that's a bit excessive ;-). The goal is to make sure that we don't have N versions of something that is likely to change. Since the source file is unlikely to change, that seems a bit silly. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
This patch is for System.Web.UI.WebControls.
If you find any problems regarding the patch itself feel free to comment it
but if you imagine any other non-blocking patches that should be done before
committing this one I promise that I will propose no more pathes.
Kornél
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]; Andreas Nahr
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED];
mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:41 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
I agree with you that this a better idea but I will never try to submit
such
a big patch for proposal because it would change too much code and it
figured out that it is nearly impossible to make any major change to Mono
because if there are no mistakes and errors in the patch itself an endless
list can be created about things that should be done before the patch can
be
comitted altought they don't block the patch in fact.
I see a lot of things in Mono that sould be made more reliable using some
centralization but I don't want to create n+1 wariants of this patch.
I reported the problem, I proposed a patch, the patch seems to be correct
(because no notices were provided regarding the patch itself). If you want
to do hundreds of things that are not required to apply the patch before
applying the patch it's up to you but I don't want to solve all the
problems
you can imagine just to commit this patch.
Anyway I think having different verion numbers than MS.NET is a more
critical issue than having a weakly centralized assembly referencing
practice.
Note that the references in System.Web.UI.WebControls are in NET_2_0 only
code blocks and these references are not in other versions. This seems to
be
consistent practice in System.Web.UI.WebControls. Centralizing the
assembly
reference could save some disk space but currently it is not required. It
will be required when a new (post 2.0) .NET Framework version will be
released but currently even 2.0 was not released yet so it will be in the
distant future.
Kornél
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
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
System.Web.tar.gz
Description: GNU Zip compressed data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] monodevelop-GtkSourceView-CRITICAL
Hi, i am a new mono programmer, i buy Mono-a developer's notebook of O Reilly and i am studing it. It's a rather good book - my main problem with it is that it looks like a school book with those silly squares on the paper. I have installed on my linux slackware notebook the latest version of mono but when i run monodevelop Which version of mono are you running, have you compiled it yourself or installed it from the rpms? i have this error: (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 681 (gtk_source_buffer_new_with_language): assertion `GTK_IS_SOURCE_LANGUAGE (language)' failed (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 1470 (gtk_source_buffer_set_highlight): assertion `GTK_IS_SOURCE_BUFFER (buffer)' failed i have found on google this link http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=PROJECT;action=display;num=1116846330 and i try to delete ./config/Monodevelop but i have always this problem :-( That is a somewhat old reply to the problem and is probably no longer the case. If you've compiled from source, then there shouldn't be a problem with monodevelop - it certainly works at this end. TTFN Paul -- Some people will do anything for a woman in uniform - The Doctor - Unregenerate (Big Finish audio) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 01:31 +0200, Kornél Pál wrote: This patch is for System.Web.UI.WebControls. If you find any problems regarding the patch itself feel free to comment it but if you imagine any other non-blocking patches that should be done before committing this one I promise that I will propose no more pathes. Gonzalo, who was smart enough to rm -rf /usr/bin on his laptop ;-), says he approves this. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] TimeStamp support on oracle...
You need to modify OciDefineHandle to deal with the TIMESTAMP.
See Define(), DefineDate(), and GetValue().
You can create a new function called DefineTimestamp() based on
DefineDate() and allocate space for it based OciDataType.TimeStamp.
What about TIMESTAMP WITH TIMEZONE and TIMESTAMP WITH LOCAL TIMEZONE?
There is also INTERVAL YEAR TO MONTH and INTERVAL DAY TO SECOND data
types. This is equivalent to System.TimeSpan and
System.Data.OracleClient types OracleMonthSpan and OracleTimeSpan.
These have not been implemented either.
Also, in OracleParameter, you need to allocate space for the Timestamp
for the output parameter, and you need to convert a .NET DateTime to an
Oracle TIMESTAMP by using OCIDateTime functions for the input parameter.
An Oracle Date uses OCIDate while TIMESTAMP uses an OCIDateTime.
You will need to DllImport into function OCIDateTimeConstruct() to
create and set the date and time in a OCIDateTime. You will also need
to DllImport into function OCIDateTimeGetTime() to get the time from the
OCIDateTime and OCIDateTimeGetDate() to get the date from the
OCIDateTime. There are other functions for the time zone, etc...
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci18map002.htm#i512069
Hubert FONGARNAND wrote:
I really need the new TimeStamp type (supported starting from oracle 9). It's
a MS.NET supported type (i've made tests)...
I've begin to do a little patch (attached) to add the timestamp type to
oracle.client...
but... I've a strange error when i try to do a Fill, it failed with:
Unhandled Exception: System.Data.OracleClient.OracleException:
in 0x0013d System.Data.OracleClient.Oci.OciStatementHandle:Fetch ()
in 0x0002c System.Data.OracleClient.OracleDataReader:Read ()
in 0x002f4 System.Data.Common.DbDataAdapter:FillTable (System.Data.DataTable
dataTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords,
System.Int32 counter)
in 0x0011f System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, System.String srcTable, IDataReader dataReader, Int32 startRecord,
Int32 maxRecords)
in 0x000d5 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, Int32 startRecord, Int32 maxRecords, System.String srcTable,
IDbCommand command, CommandBehavior behavior)
in 0x00044 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet)
in 0x007b8 ConsoleIntranet.Class1:TestTimestamp ()
in 0x00015 ConsoleIntranet.Class1:Main (System.String[] args)
Could someone help me how to resolve this issue?
thanks
___
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce
message non conforme à sa destination, toute diffusion ou publication, totale
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce
message n'est pas assurée et la société émettrice ne peut être tenue pour
responsable de son contenu.
Index:
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
===
---
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
(revision 47807)
+++
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
(working copy)
@@ -258,7 +258,7 @@
OciDataType bindType = ociType;
IntPtr bindValue = IntPtr.Zero;
int rsize = 0;
-
+ Console.WriteLine(Parametre : +ociType.ToString());
// TODO: handle InputOutput and Return parameters
if (direction == ParameterDirection.Output) {
// TODO: need to figure out how OracleParameter
@@ -324,9 +324,11 @@
bindSize = 0;
}
else {
+ Console.WriteLine(OracleType
+oracleType.ToString());
// TODO: do other data types and oracle data
types
// should I be using IConvertible to convert?
if (oracleType == OracleType.DateTime) {
+ Console.WriteLine(DATE!!!);
string oraDateFormat =
connection.GetSessionDateFormat ();
string sysDateFormat =
OracleDateTime.ConvertOracleDateFormatToSystemDateTime (oraDateFormat);
@@ -637,8 +639,11 @@
dbType = DbType.AnsiStringFixedLength;
ociType = OciDataType.Char;
Re: [Mono-devel-list] Key Exchanges (RSA vs DH)
Hello Thomas, On Thu, 2005-28-07 at 03:50 -0400, Thomas Harning Jr. wrote: I'm trying to evaluate key exchange algorithms for both speed, security, and verification [S, S, V]. I was thinking of using RSA mainly, but I ran accross some info about DiffieHellman being good for key exchange. This may, or not, be relevant to your application but DH is for key *agreement* not key exchange - so it's not exactly the same. I plan on using the key exchange algorithm in exchanging keys for say... Rijndael or some other configurable algorithm. I know a bit about RSA, but not much about DH. I know for RSA the key generation process is ugly (timewise), very true (but for some good reasons ;-) but I can't remember how the encryption/decryption process is. better. In fact *much* better when CRT can be used (i.e. when the private is used and all the extra information are available). It seems DH is pretty fast, but I'm unsure as to how to configure it properly for my needs [ S,S,V ]. In running a few tests, I found that the static key 'generation' works pretty good, you would probably get very similar times for RSA encrypt/decrypt operations when using a pre-generated key - i.e. this doesn't mean using a static key! though to me, it looks pretty unsafe. Is it? well it would be for a key exchange - but it's not for a key agreement ;-) however YMMV with how you're using the stuff With Static key generation, I didn't need to do any passing of public key information (though it would obviously be the same w/ static key)... which leads me to believe that it's relatively pointless. Also, there's 2 lengths to specify, but I don't know what really affects what. [As an aside, a patch to rename the length's names to something more meaningful would be nice... I may make a patch when I better understand how it works] Thanks for your help, sorry about the relativly messy train of thought. I've more confidence in the maths behind the crypto (both for RSA and DH) than in any software/hardware implementation of them - and MUCH more confidence in the 'wares implementations than in (most) software using them ;-) So I suggest you get a good look at some crypto book like Applied Cryptography or the more recent Practical Cryptography and/or stick as much as possible(tm) with industry standards. Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Npgsql breaks multi-line queries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rafael Teixeira wrote: I've forwarded your patch to Francisco Jr. that created/maintains npgsql, as the primary repository for it is at gborg under his control, and is just synced inside Mono's. Thanks for spotting that, Hi Rafael, Jaroslaw. Fixed in svn. Thanks for patch! - -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://gborg.postgresql.org/project/npgsql MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - Science without religion is lame; religion without science is blind. ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQum21P7iFmsNzeXfAQJAlQgAj9NpoAb9iTIRvvjoqyTPYdAGirdg1NPk KfC62rttzRQlt9byaRCTs+WaHjN+l1amdRuPfXM6hBnm1OJThkOkEWvPs8E6T1ax MM8l/H/JTbtylESDj1pzQgie9S1TaRbIdDVaJV2eIPSqP/4ngcnXdUF5ST1risex 1ca7IuLivCjpTDBEGKS5FEkcGoVL+2FbqQ2v6fiVzU7hMlyklIvghO3Zogkq2cOf FPjEj61jItBvTxPnTKC5gyvNln3D+8nckxv7rKKeryNgV2FqX9yje2/jf7G63pi3 1G2Ay9bDr/NVk5+YkymcAx4TFN5jUbx3gyjKaG0gJi4eYz4F+7+5gQ== =/x8B -END PGP SIGNATURE- ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
