I probably shouldn't cross-post, but i wasn't sure where to put this, or
if i should file a bug report (I'm new-ish to mono). After reading the
mailing list description, this seemed like a more appropriate place to ask.
First, let me say this is not a critical problem, and i'm not sure
I am _not_ an expert in mono, nor have i ever compiled mono, but...
It looked like it's trying to access a library that's not there -- the
library should be in the mono/mini directory and named libmono-2.0.1a
(or something like that).
Have you tried going into the mono/mini directory and
is working correctly.
*From:* Rob Wilkens robwilk...@gmail.com
*To:* mono-devel-list@lists.ximian.com
*Sent:* Friday, April 27, 2012 2:57 PM
*Subject:* [Mono-dev] System.Data.SqlConnection fails on 2nd invalid
login attempt
I
.
*From:* Rob Wilkens robwilk...@gmail.com
*To:* mono-devel-list@lists.ximian.com
*Sent:* Friday, April 27, 2012 2:57 PM
*Subject:* [Mono-dev] System.Data.SqlConnection fails on 2nd invalid
login attempt
I probably shouldn't cross-post
*From:* Rob Wilkens robwilk...@gmail.com
*To:* mono-devel-list@lists.ximian.com
*Sent:* Friday, April 27, 2012 2:57 PM
*Subject:* [Mono-dev] System.Data.SqlConnection fails on 2nd invalid
login attempt
I probably shouldn't cross-post, but i wasn't sure where to put this,
or if i should file a bug
[apologies if duplicated - i sent from wrong account at first and don't
think it went through]
I hate trying to get other people's program's to build properly on a
different computer than it was originally built on/for, but i gave
building mono an honest effort before giving up. I've been
[this reply to list -- my earlier replies were off list, but i figure a
public 'thanks' was in order..]
Thanks again to all that replied. I am going to try again today using
the following:
-i am installing to /home/.../mono -- and i am going to give another
shot at the git version rather
Ok, I've managed to get rid of most of my errors via using the
parallel build environment configuration...
But I've got one more error preventing me from proceeding with what i
wanted to work on, and i think it's related to gtk-sharp, in which
case i'm either asking on the wrong mailing list
can't figure out another work-around, I'll be
back here later.
If you don't hear from me, presume it worked.
-Rob
On 05/01/2012 08:45 AM, Rob Wilkens wrote:
Ok, I've managed to get rid of most of my errors via using the
parallel build environment configuration...
But I've got one more error
Copying list on my reply, sorry i keep forgetting i have to reply all..
On 05/01/2012 10:09 AM, Rob Wilkens wrote:
2.12.10 was the version i was building -- and yes, i suspect i have a
gtk3 system (unity/ubuntu 12.04)...
I could try the experimental branch, but for what i'm doing right now
I hate trying to get other people's program's to build properly on a
different computer than it was originally built on/for, but i gave
building mono an honest effort before giving up. I've been trying
different troubleshooting steps for something like 5 hours now; and that
doesn't count
need to install libgtk2.0-dev via apt-get then?
/Oskar
2012/5/1 Rob Wilkensrobwilk...@gmail.com:
Copying list on my reply, sorry i keep forgetting i have to reply all..
On 05/01/2012 10:09 AM, Rob Wilkens wrote:
2.12.10 was the version i was building -- and yes, i suspect i have a gtk3
I found out the fix for the error i reported with multiple invalid
login attempts... It's very simple...
Mono.Data.TdsClient.TdsConnectionPool.cs
In the above file, in GetConnection(), either before:
goto retry
or after the initial
retry:
(either place should be fine)
result needs to be
to the
mailing list.
Does the below suffice as a patch or should i figure out the 'github'
way which i thought i saw elsewhere.
-Rob
On 05/01/2012 11:49 AM, Rob Wilkens wrote:
I found out the fix for the error i reported with multiple invalid
login attempts... It's very simple
changes after that. I was guessing it might be a year or more before my
fix reached me ;-).
-Rob
On 05/02/2012 01:53 AM, David Schmitt wrote:
On 2012-05-01 03:44, Rob Wilkens wrote:
Ok, So i'll get to where i'm at now:
1) I did an apt-get source mono ran an autogen, make. (and
eventually make
the bottom of the page where it simply says to submit the
patch to the mailing list.
Does the below suffice as a patch or should i figure out the
'github' way which i thought i saw elsewhere.
-Rob
On 05/01/2012 11:49 AM, Rob Wilkens wrote:
I found out the fix
I came up with a Nunit test that :
(1) Demonstrates the failure i reported
(2) Demonstrates that it is fixed with my patch
(My git directory is separate from my build directory)
My plan, if i remember tomorrow, is to commit this change to github,
push it, and do another pull request.
Do i
includes it.
-Rob
On 05/03/2012 07:46 AM, Rodrigo Kumpera wrote:
Separate is fine. Tests are always welcome.
Thanks for taking time on this.
On Wed, May 2, 2012 at 11:10 PM, Rob Wilkens robwilk...@gmail.com
mailto:robwilk...@gmail.com wrote:
I came up with a Nunit test that :
(1
.
On Wed, May 2, 2012 at 8:26 AM, Rob Wilkens robwilk...@gmail.com
mailto:robwilk...@gmail.com wrote:
[resending reply via reply to list only, left off list in previous
reply]
I already did the pull request on github -- and i'm not sure how
to include the tests (I only commented
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
After fixing the bug i reported myself a few weeks ago, i had my
doubts as to whether the commit would be accepted as a newbie here.
But it was!
So, i'm hooked! I just submitted another patch(commit) today via
github.
This one for bug #853
On 05/25/2012 05:09 PM, Rodrigo Kumpera wrote:
I love to see people excited with contributing to mono.
Thanks for taking take to do this. Everyone in the community
appreciate your effort.
On Fri, May 25, 2012 at 5:56 PM, Rob Wilkens robwilk...@gmail.com
wrote:
After fixing the bug i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I appreciate the link --- I bookmarked the novell link right next to
the other bug list (same folder), thanks, and will reference it when i
have time to look at more bug reports. I saw the novell bugs links at
http://mono-project.com/Bugs but i
I presume this is a gtk# problem, but not really, because i am running
an old version of gtk# which worked with previous versions of mono...
With the latest mono builds, with the same gtk# libraries, etc., that
was running in 2.11.2 just fine, I have issues with monodevelop menus
not showing
Without giving the specific code changes, which i'll commit and push to
github later if i don't get objections, I'm curious if any of the more
experienced developers here (anyone who's done more changes than me,
which is one or two) want to comment on the following bug report and
proposed fix
--this is unrelated to my immediately previous e-mail, that e-mail was
about a bug report by someone else that i had a question on--
Ok, I earlier this morning reported that under my parallel mono
environment (local build) monodevelop runs but it has no top level menu
(No File, Run, etc.)...
Actually, the behavior is not identical to Windows (jut checked now).
At least not in my virtual machine.
Give me some time to troubleshoot further.
-Rob
On 05/30/2012 02:01 AM, Stifu wrote:
So, there is nothing left to fix in this bug, and Mono behaves the same as
.NET. Is that right?
By
Ok, I was wrong, there is a difference between the way Microsoft does it
and the way Mono does it, and the way Microsoft does it makes more sense:
The second Application.Run() that is reached in Microsoft code
immediately exits.. It doesn't go into a message loop.
The second
I'm troubleshooting a problem in System.Windows.Forms (or an application
which uses it):
Does anyone know of problems where messages processed from thread a
can't reach a window created in thread b? That is, if thread a is
processing messages, those messages don't reach the windows created
Thanks! I thought there was supposed to be only one UI thread.
That is useful information (your sample code). I may use it as i
troubleshoot further.
I don't want to change the code i have, though, because again this code
in the report i have somehow manages to work in Windows. But i
Incidentally (and this is not a personal reply, this is gereral to
anyone interested), relating to the below reply, unlike .NET, in mono
more than one thread can be processing the message loop, and delivering
the same UI messages to more than one thread.
That is, more than one thread can
(This is re: System.Windows.Forms)
IT appears Control.Dispose is destroying the parent window, then
destroying the children... Is it supposed to do that?
This is causing some warning messages from X11 in my test code under
some circumstances, at least when the window is created under
I don't have a similar failure with the same version as build by the
debian package that ubuntu ships with (which is the same version
2.10.8.1) But i'm on a different platform i believe (x86-64).
I looked at the ubuntu source, and it appears to be failing here for you:
On 05/30/2012 03:56 PM, Rob Wilkens wrote:
I'm troubleshooting a problem in System.Windows.Forms (or an
application which uses it):
Does anyone know of problems where messages processed from thread a
can't reach a window created in thread b? That is, if thread a is
processing messages
I've come up with as close to a good fix for Novell #321541 as I could
think of, and it works for the sample code provided in the bug report.
Ignore my comments on that report, i originally looked at the problem
wrong, and made some incorrect statements -- I haven't posted anything
current
Ok, I just submitted to github my patch for a 6 year old bug. I'm a
little uncomfortable with not being able to test on every possible
platform, but i don't really have all the platforms available to me. I
confirmed it works well enough on X11. I also included unit tests.
I fully
: Rob Wilkens
Sent: 6/2/2012 7:20 AM
To: mono-devel-list@lists.ximian.com
mailto:mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Patch for 6 year old bug ;-) - Submitted to github
Ok, I just submitted to github my patch for a 6 year old bug. I'm a
little uncomfortable with not being able
On 06/02/2012 08:55 PM, Steven Boswell II wrote:
The EditingControlShowing event has to be called, and it has to be
called after the control's contents have been initialized
properly...that's not really two separate issues.
The enclosed patch is an updated version; in addition to having a
On 06/02/2012 09:38 PM, Rob Wilkens wrote:
On 06/02/2012 08:55 PM, Steven Boswell II wrote:
The EditingControlShowing event has to be called, and it has to be
called after the control's contents have been initialized
properly...that's not really two separate issues.
The enclosed patch
On 06/02/2012 11:20 PM, Steven Boswell II wrote:
Argh...one more dumb oversight in my change.
Enclosed is ANOTHER version of the patch.
I wish I had the luxury of working on my hobbies when I was awake and
energetic. ;-)
Steven Boswell
I guess that is a luxury i have ;-).. i don't/can't
I haven't pulled in the latest code changes, and i know there were some
recent patches on DataGridView but have there been any changes on DataGrid?
I was looking at the sample code in this closed bug:
https://bugzilla.novell.com/show_bug.cgi?id=MONO79788
And it crashes on me if i click on the
it.
And whoever was assigned to WinForms bugs in 2006, don't expect anything to
get done (obviously, after 6 years...). The Mono team announced they
wouldn't work on WinForms anymore, and that it was up to the community to
maintain it.
Rob Wilkens wrote
I haven't pulled in the latest code
On 06/03/2012 05:30 PM, Stifu wrote:
If this particular bug hasn't been reported, then yeah, go ahead and report
it.
And whoever was assigned to WinForms bugs in 2006, don't expect anything to
get done (obviously, after 6 years...). The Mono team announced they
wouldn't work on WinForms anymore,
Steven,
What I like to do with generating unit tests (and i'm new to this too)
is this;
(1) before making any changes, clone the git tree twice, one i put in a
directory called 'mono-orig', the other i just put in 'monosrc'. I like
to pre-compile them both long in advance, so when i make
I just read the whole document, and decided to bookmark it, I'll try to
refer to it often, it's a well written document. The only part i was a
little lost on was re: git and backporting. I don't even know what it
means to backport, but then i'm new to git in general.
I understand very
Thanks for sharing .
I'm glad to know i'm not alone here with the submitting patches only to
repatch them thing ;-), my last patch (submitted via github) had 3
patches to it after one comment by another developer who pointed out
something i missed entirely the first time. All of the patch
On 06/05/2012 07:34 AM, Andres G. Aragoneses wrote:
On 05/06/12 02:26, Rob Wilkens wrote:
I submitted two unrelated fixes on the same pull request today which had
other fixes queued. I know that makes it more complicated to pull in the
changes if they're determined to be acceptable in the end
:27 AM, Rob Wilkens wrote:
On 06/05/2012 07:34 AM, Andres G. Aragoneses wrote:
On 05/06/12 02:26, Rob Wilkens wrote:
I submitted two unrelated fixes on the same pull request today which
had
other fixes queued. I know that makes it more complicated to pull in
the
changes if they're determined
!' (I found it!) but 'That's funny ...'
Isaac Asimov
US science fiction novelist scholar (1920 - 1992)
On Tue, Jun 5, 2012 at 1:32 PM, Rob Wilkens robwilk...@gmail.com
mailto:robwilk...@gmail.com wrote:
Help! I followed the directions in the webpage to create another
fork of the main
I still have to clean up the code, and create a branch, and submit it,
but i just fixed a 5 year old bug and if anyone has issues with how i
did it here is a summary
the problem report is here:
https://bugzilla.novell.com/show_bug.cgi?id=323154
I found by deduction that the repaint wasn't
I won't commit that change i just mentioned until tomorrow at the
earliest. However, i'm wondering if i should just tack it onto the
existing pull request because that pull request already modifies the
same file (DataGrid.cs).
___
Mono-devel-list
Ok, I created a branch bug2663, i made a biggish patch, created a well
versed description for the commit, ran a 'git push', then went to
github, and my change is nowhere to be found.
I tried pulling down on my list of branches (where it says Master) and
there is no bug 2663 branch or
Nevermind, seconds after i wrote this i found i was missing:
$git push origin bug2663
all is well
On 06/07/2012 08:04 PM, Rob Wilkens wrote:
Ok, I created a branch bug2663, i made a biggish patch, created a
well versed description for the commit, ran a 'git push', then went to
github
Ok, as i mentioned yesterday, I submitted a patch for Xamarin bug
#2663. I expect it to be delayed by prior patches which are queued
ahead of it from me. It's possible someone won't like my implementation
too, but at least it does fix the bug, and this time i generally tried
to stay within
Does anyone know: Is WPF Considered open like .net is, or is the fact
that W stands for Windows in it mean that it is inherently closed..
Incidentally, i was just looking at Visual Studio 2010 (not 2012,
haven't tried it yet) last night and i noticed the default project type
is still
On 06/09/2012 03:03 AM, Stifu wrote:
Rob: WPF is no more open than WinForms, and both start with Windows
anyway.
By the way, as far as I'm concerned, WPF is pretty much dead (possibly
more-so than WinForms). At first, the Mono team didn't want to implement it
because it was too big, too complex,
On 06/09/2012 02:49 PM, Steven Boswell II wrote:
Also, I noticed that bringing up a dialog box before calling
Application.Run() tends to make Mono freak out. Maybe that's the
problem with your DgwTest project? The enclosed ComboBoxTest project
waits until the Form's Load event to bring up
Re:
https://bugzilla.novell.com/show_bug.cgi?id=324258
I ran the sample code on mono 2.10.8.1 and it appears to work correctly
(it functions the same on Linux and on Windows -- that is, it gets a
Focus event at start-up even though OnLoad is overridden.
I've never closed a bug report myself
Well, I downloaded DgwTest.zip from the previous e-mail
And I added to MainForm() (i.e. the constructor) a call to
MessageBox.Show(test 2) and that worked, and for good measure, I added
a similar call to MessageBox.Show(test) to Program.cs before
Application.Run() is reached -- both times the
I was reviewing my submission here:
https://github.com/mono/mono/pull/312/files
And I realized i wasn't consistently following the suggestions about
proper use of whitespace.
Should i change and make yet another commit which fixes this, or would
that just be ugly having more commits?
If i
Ok, I've corrected the Whitespace issues... You will only see the
changes in pull request one of two because pull request 2 is on a
different branch even though it contains some of the same commits.
I've also now labelled my pull requests in the sequence they are
intended to come in..
I
started building all of mono on cygwin, should i expect problems?
Not especially, it's just going to take a while if you do it each time.
By the way, I don't have a Mac, so I won't be able to review your
Mac-related patches.
Rob Wilkens wrote
I started building all of mono on cygwin, should i expect
If anyone was interested, I found the config file i was looking for here
/Library/Frameworks/Mono.framework/Version/2.10.8/etc/mono
When i copied that config file to ~/.mono I then got past that
particular error.
I see that it is still somewhat buggy (no more with my patch than
without
Ok, with or without my patch from my oldest pull request, the unit tests
freeze up on a mac for system.windows.forms. So i can't run my unit
test. I had to update the config in the source directory
(runtime/etc/mono) with the config file from my mac's install for the
tests to really run at
The parallel library documentation
http://www.mono-project.com/Parallel_Mono_Environments says to set a
environment variable called:
DYLD_LIBRARY_FALLBACK_PATH
But on a mac just setting that environment variable gives me constant
errors until i unset it
I looked up the documentation
I'll re-open them after i figure out why my unit tests fail on windows.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
I haven't been able to dig into the code too much yet.. But...
From what i can see XplatUIWin32 only call OnIdle event handlers when
Application.RaiseIdle(EventArgs e) is called by the application.. It
doesn't actually call it when the application goes idle.
I've been researching the Windows
I'm getting the following exception sporadically while testing my sample
code that is used as a unit test (though i've never had it fail as a
unit test) both with and without my patch, even with mono 2.10.8 but
this is only happening on Windows...
System.MemberAccessException: Object is busy
In my local copy of mono (robwilkens/mono on github) I can build in
cygwin just fine...
In the real mono/mono, i get the following error:
In file included from ../../eglib/src/glib.h:7,
from socket-io.c:20:
/usr/i686-pc-mingw32/sys-root/mingw/include/stdio.h:536: warning: no
I just used a goto in a patch i submitted tonight too: I enabled the
ability of Win32 to send an idle event message when the app goes idle.
Previously, Win32 mono was not doing that.
Sent on github, if someone wants to review. I tested relevant code on
relevant platforms.
-Rob
On
I'll modify (already have now, just have to re-run the tests) the unit
test. The unit test wasn't failing in Windows the way it was written,
but it was always failing for me outside of the unit test. Now I have
it passing outside of the unit test with this below change in Windows,
just have
On 06/12/2012 12:56 PM, Jonathan Pryor wrote:
On May 31, 2012, at 4:36 PM, BigalGeorge wrote:
Hi is mono capable of browsing the hidden directories under Linux? Why I ask is
that I have enabled them for viewing under Ubuntu eg are visible in Nautilus,
but when using mono browser they are
First, if you're an important person with too much to do, feel free to
skip this message. I just wanted to write a little about my last 3 days
worth of mono related testing and such.
Ok, So I found a bug in my first patch that was sitting in my queue...
At first, it only happenned in
Well, as much as i would like to take a guess at an answer, my
suggestion is to contact the Duplicati developers rather than the mono
developers. They would know what they used as a 'file browser' and what
the options it has are.
I am not an expert, though, and someone with more expertise
On 06/13/2012 02:47 PM, Michael Hutchinson wrote:
On 12 June 2012 17:40, Rob Wilkensrobwilk...@gmail.com wrote:
Well, as much as i would like to take a guess at an answer, my suggestion is
to contact the Duplicati developers rather than the mono developers. They
would know what they used as a
I wanted to think about what to work on next, and i wonder if anyone has
an opinion on this:
In my testing of .net winforms on windows i received a lot of gdi+
object busy errors when i was testing a multithreaded app, regardless of
what thread the form was 'created' in (what thread the form
[long story short: Got to troubleshoot some more, but the answer is that
these apps are functional in windows, attached a sample]
In Windows.NET it definitely works, both the code sample from the bug
report (which, incidentally, is not running for me right now, so i've
pulled back my pull
just ran it from the command prompt about 30-40 times in a row in .net. So
that should run in mono, no?
Yes, I was just confused by your original post: In my testing of .net
winforms on windows i received a lot of gdi+ object busy errors, which made
it sound like the errors were .NET ones.
Rob
I don't mean to get involved, but there was a line number and a file so
i looked...
I'm not sure if this helps or not, but i looked at the line that failed,
presuming it hasn't changed since my copy was downloaded:
It's:
if (msg.Headers.To == null)
And if that's the case, what's probably
Just as a double check, msg might not be null and msg.Headers could be
null and that could be causing the problem too.
-Rob
On 06/13/2012 08:52 PM, shahbour wrote:
Thanks rob
I have added a condition above this to check if msg == null to return
false same as the post above it do.
So
wrote:
Certain warning have been made into errors as the warnings are
not safe on 64-bit builds. I am looking into fixing the build now.
Thanks,
Jonathan
On Mon, Jun 11, 2012 at 9:23 PM, Rob Wilkens
robwilk...@gmail.com mailto:robwilk...@gmail.com wrote
Hope this helps to clarify things.
Have a nice weekend,
Matthias
On Fri, Jun 15, 2012 at 11:47 PM, Rob Wilkens robwilk...@gmail.com
mailto:robwilk...@gmail.com wrote:
Jonathan,
I would love to help with this, on some level, but i would have to
submit patches via a patchfile
Shahbour wrote:
Yes I will but this is the first time I do that if you can show me how I
will be thankful.
BR
Shahbour
On 6/16/12 12:11 AM, Rob Wilkens robwilk...@gmail.com wrote:
Was this the null check?
If so, perhaps we need to submit some sort of official patch, if you
didn't already
file suitable for use with git apply.
*From:* Rob Wilkens robwilk...@gmail.com
*To:* Jonathan Chambers jonc...@gmail.com
*Cc:* mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.com
*Sent:* Friday, June 15
the patience to do another one tonight, cygwin is
just too slow (at least in a vm). Let me know if the other patch i
submitted is OK.
-Rob
On 06/15/2012 08:26 PM, Rob Wilkens wrote:
This is an untested patch, my windows installation is slow as crap,
i'm working on it, but let me know what you think
I know my opinion is of mixed value, but it looks to make sense to me..
If the toolstripitem is being changed so it no longer has an owner,
calculating a size might not make sense
-Rob
On 06/15/2012 08:34 PM, Steven Boswell II wrote:
Enclosed is a new patch, mostly for discussion purposes,
This one seems to get a lot further -- but it's still slowly compiling.
It's gone about 10 minutes now compiling without a failure on win32.
Take a look at the attached patch, feedback welcome.
(For reference, this is supposed to help solve the problem with cygwin
compiling of the current mono
On 06/15/2012 09:44 PM, Rob Wilkens wrote:
This one seems to get a lot further -- but it's still slowly compiling.
It's gone about 10 minutes now compiling without a failure on win32.
Take a look at the attached patch, feedback welcome.
(For reference, this is supposed to help solve
On 06/15/2012 09:44 PM, Rob Wilkens wrote:
This one seems to get a lot further -- but it's still slowly compiling.
It's gone about 10 minutes now compiling without a failure on win32.
Take a look at the attached patch, feedback welcome.
(For reference, this is supposed to help solve
On 06/15/2012 10:16 PM, Rob Wilkens wrote:
I've attached a third attempt after finding one more problem with the
compile (took about 30 minutes to reach) -- i'm probably near done for
the evening
Good news, after the third patch attempt, i now get up to the [MCS]
portion of the patch, which i
On 06/15/2012 10:19 PM, Rob Wilkens wrote:
On 06/15/2012 10:16 PM, Rob Wilkens wrote:
I've attached a third attempt after finding one more problem with the
compile (took about 30 minutes to reach) -- i'm probably near done for
the evening
Good news, after the third patch attempt, i now get up
on this mailing list... ;-)
From: Rob Wilkens lt;robwilkens@gt;
To: mono-devel-list@.ximian
Sent: Friday, June 15, 2012 5:42 PM
Subject: Re: [Mono-dev] Patches for mono-winforms
I know my opinion is of mixed value, but it looks to make sense to me
*From:* Rob Wilkens robwilk...@gmail.com
*To:* mono-devel-list@lists.ximian.com
*Sent:* Saturday, June 16, 2012 5:41 PM
*Subject:* Re: [Mono-dev] Patches for mono-winforms
As per the test project mentioned, I just tested with Microsoft Visual
Studio 2010 professional, on Windows 7
it with
patched Mono or with .NET, I wouldn't. What exactly did you do?
Steven Boswell
From: Rob Wilkens lt;robwilkens@gt;
To: mono-devel-list@.ximian
Sent: Saturday, June 16, 2012 5:41 PM
Subject: Re: [Mono-dev] Patches for mono-winforms
As per the test project
Ok, it fails for me in windows with this patch applied, i'm going to see
if i can unapply this patch (just 'git checkout file' should do it i
think...
Here's the error i get:
1-1: expected not null, found null.
-Rob
On 06/17/2012 06:33 AM, Rob Wilkens wrote:
I figured out git apply and am
, Rob Wilkens wrote:
I figured out git apply and am going to test this in windows now.
I am going to do this from a cygwin build.
It may be a little while before the build and make install are done.
-Rob
On 06/17/2012 06:20 AM, Robert Wilkens wrote:
Do you want me to try this? Does it make
in windows with this patch applied, i'm going to see
if i can unapply this patch (just 'git checkout file' should do it i
think...
Here's the error i get:
1-1: expected not null, found null.
-Rob
On 06/17/2012 06:33 AM, Rob Wilkens wrote:
I figured out git apply and am going to test
Ok, if you are willing to look at it, i've attached it if i did it right...
I did a git diff commit just before first commit last commit
That should have the whole range of changes of all the commits,
hopefully i've attached the right file too.
This should align with the following pull
I've attached what i think is the test outside of nunit (found it
sitting in my home directory)..
gmcs FormEventTest.cs -R:System.Windows.Forms.dll -R:System.Drawing.dll
If you see:
error4
error3
error1
That means it failed
If you don't see anything but two windows flash by, that means it
I won't have time to do that right now, but will later, please be
patient.. I wouldn't wait around the keyboard right now for an e-mail
because i'm next in line for the shower then we're heading out for morning.
The bug reports are listed on the pull page, but i will try to separate
the
a dependency on a previous commit going through.
-Rob
On 06/17/2012 09:34 AM, Stifu wrote:
Alright, I'm not in a hurry.
Rob Wilkens wrote
I won't have time to do that right now, but will later, please be
patient.. I wouldn't wait around the keyboard right now for an e-mail
because i'm next
1 - 100 of 179 matches
Mail list logo
