wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] WxcDefs

[Eric K. <eri...@gm...>]

Hi Fernando,

On Mon, Oct 12, 2009 at 20:29:50 -0300, Fernando Benavides wrote:
> 	If you check the sources of wxMac-2.8.10 you'll find a file called  
> include/wx/defs.h.  According to this file, for example, wxID_FIND is  
> 5035 but Graphics.UI.WXCore.WxcDefs.wxID_FIND is defined as 5034 and  
> Graphics.UI.WXCore.WxcDefs.wxID_DUPLICATE is 5035.

Sounds like a bug.  I see that the above module is autogenerated, but I
suppose the problem is that the underlying Eiffel file wx_defs.e has
this misset.

So this looks like us falling afoul of the old maxim: Duplication is the
root of all evil.

Do you think you could possibly investigate how to generate from the
wxWidgets headers directly instead of from our own hard copy?

I believe all the wxHaskell developers are busy, and in any case focused
on getting the new wxcore stuff ( git clone git://github.com/bsl/wxcore )
working better with Windows and integrated into the main Darcs
repository.  If we could polish this work off and fix Conal's GHCi
problem, we could have a really nice release on our hands, gain some
ground back from gtk2hs, native widgets FTW.

Eric

PS: I have a snippet of Haskell code to generate application bundles
    directly as a Cabal install hook.  No more silly macosx-app script.
    Perhaps I should stick it on hackage or something...

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

[wxhaskell-users] WxcDefs

[Fernando B. <gre...@gm...>]

Hi people,
	I'm trying to add a menu to my wxhaskell app.  I'm working with the  
latest wxhasell version (downloaded using darcs) and wxMac-2.8.10 and  
I think that there're some incongruences between them.  More  
specifically, in WxcDefs.
	If you check the sources of wxMac-2.8.10 you'll find a file called  
include/wx/defs.h.  According to this file, for example, wxID_FIND is  
5035 but Graphics.UI.WXCore.WxcDefs.wxID_FIND is defined as 5034 and  
Graphics.UI.WXCore.WxcDefs.wxID_DUPLICATE is 5035.
	I didn't check other platforms or wx versions, but in OSX Find is  
working as Duplicate (i.e. the menu is not enabled until something is  
selected).

[wxhaskell-users] WxAUI

[Fernando B. <gre...@gm...>]

Hi everybody, I'm developing λPage (http://elbrujohalcon.github.com/hPag 
e), a software to help development in haskell written in haskell.  I'm  
using wxHaskell for the GUI but I'm not completely satisfied with it.   
I know that wxWidgets has a library called WxAUI (http://www.kirix.com/labs/wxaui/design-overview.html 
) that seems to be pretty useful to achieve what I'm looking for.  Is  
there any plan to add support for WxAUI in wxHaskell?  Is there  
something like that already included in wxHaskell?

Cheers :)

[wxhaskell-users] wxHaskell and threads: FAQ is still best advice?

[Andy G. <ha...@gi...>]

Hi all,

I just wanted to ask whether the FAQ entry on multiple threads at

http://haskell.org/haskellwiki/WxHaskell/FAQ

is still the best advice?  It mentions GHC 6.0, but I wondered if  
things had changed since then.

Thanks!

-Andy

Re: [wxhaskell-users] Keyboard problem

[Henk-Jan v. T. <hj...@ch...>]

I wouldn't know where to begin debugging, but GHC has at least a  
reasonable debugger nowadays:
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-debugger.html

Regards,
Henk-Jan van Tuyl


--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--


On Fri, 09 Oct 2009 17:37:06 +0200, carlos gomez <car...@gm...>  
wrote:

> mmm I think the problem is with ubuntu and wxhaskell.
> I would like to debug it, but I don't know how.
>
> 2009/10/9 Henk-Jan van Tuyl <hj...@ch...>
>
>> On Fri, 09 Oct 2009 10:25:21 +0200, carlos gomez <car...@gm...>
>> wrote:
>>
>> > Hello,
>> > I tried to play wxAsteoids game but i couldn't, the keyboard did't  
>> listen
>> > me.
>> >
>> > Does someone have problems with the keyboard?, how can I fix it?
>> >
>> > I'm using ubuntu 9.04 + GHC 10.4 + wx-0.11.1.2 + wxcore-0.11.1.2.
>> >
>> >
>> > regards carlos
>>
>> It works fine for me.
>> I'm using Windows XP + GHC 6.10.4 + wx-0.11.1.2 + wxcore-0.11.1.2.
>>

-- 

Re: [wxhaskell-users] Keyboard problem

[Henk-Jan v. T. <hj...@ch...>]

On Fri, 09 Oct 2009 10:25:21 +0200, carlos gomez <car...@gm...>  
wrote:

> Hello,
> I tried to play wxAsteoids game but i couldn't, the keyboard did't listen
> me.
>
> Does someone have problems with the keyboard?, how can I fix it?
>
> I'm using ubuntu 9.04 + GHC 10.4 + wx-0.11.1.2 + wxcore-0.11.1.2.
>
>
> regards carlos

It works fine for me.
I'm using Windows XP + GHC 6.10.4 + wx-0.11.1.2 + wxcore-0.11.1.2.

-- 
Met vriendelijke groet,
Henk-Jan van Tuyl


--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--

[wxhaskell-users] Keyboard problem

[carlos g. <car...@gm...>]

Hello,
I tried to play wxAsteoids game but i couldn't, the keyboard did't listen
me.

Does someone have problems with the keyboard?, how can I fix it?

I'm using ubuntu 9.04 + GHC 10.4 + wx-0.11.1.2 + wxcore-0.11.1.2.


regards carlos

Re: [wxhaskell-users] Investigating wxHaskell's die-on-restart problem

[Eric Y. K. <eri...@gm...>]

On Fri, Oct 02, 2009 at 21:52:09 -0700, Conal Elliott wrote:
> I spent some time today tracking down the die-on-restart problem with
> wxHaskell.

Yay!

> I didn't get the the heart of the problem, though I may have gotten close.
> This note records my journey, in the hope that together we can get further.

Three notes:

1. We should write a demonstrator just using wxcore, run and no start;
   this should be trivial

2. How about running this through gdb?

3. I can't seem to reproduce this crash anymore in Brian's recabalised
   wxcore.

   I think it'd be a really good idea to push the wxcore stuff into the
   Darcs repo now that it builds under Windows (albeit with some extra
   flags).

   In the meantime, you can try
      git clone git://github.com/kowey/wxcore

   Which contains Brian Lewis's recabalisation work plus one tiny
   Mac-specific bit, linking with libstdc++.  Note however that while
   I could run the StartStart demonstrator from the command line, when
   I tried to run it from GHCi, I got this:

      Loading package wxcore-0.11.1.3 ... can't load .so/.DLL for: stdc++ (dlopen(libstdc++.dylib, 9): image not found)

   Brian: any thoughts?

Thanks!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

[wxhaskell-users] Investigating wxHaskell's die-on-restart problem

[Conal E. <co...@co...>]

I spent some time today tracking down the die-on-restart problem with
wxHaskell.


Here's a simple demo of the problem:

    import Graphics.UI.WX
    main = io >> io where io = start (frame [] >> return ())

(See
http://sourceforge.net/tracker/?func=detail&atid=536845&aid=1610984&group_id=73133.)

In practice, the die-on-restart problem happens commonly when using
wxHaskell in ghci.  This behavior is why I stopped using wxHaskell and
switched to gtk2hs, though I'd love to change back, since wxHaskell is a
more elegant library, and gtk2hs and open don't work together under native
os x (and the X-based macports version generates ugly GUIs).

I didn't get the the heart of the problem, though I may have gotten close.
This note records my journey, in the hope that together we can get further.



In Graphics.UI.WX (in the wx package):

    -- | 'start' runs the GUI.
    start :: IO a -> IO ()
    start io
      = run (unitIO io)

In Graphics.UI.WXCore.Types (wxcore):

    -- | Ignore the result of an 'IO' action.
    unitIO :: IO a -> IO ()
    unitIO io
      = do io; return ()

In Graphics.UI.WXCore (wxcore):

    -- | Start the event loop. Takes an initialisation action as argument.
    -- Except for 'run', the functions in the WXH library can only be called
    -- from this intialisation action or from event handlers, or otherwise
bad
    -- things will happen :-)
    run :: IO a -> IO ()
    run init
      = do appOnInit (do wxcAppInitAllImageHandlers
                         init
                         return ())
           performGC
           performGC

I guess the unitIO in start is unnecessary, and start == run.

Appartently, the fatal re-initialization happens in appOnInit or
wxcAppInitAllImageHandlers, or maybe both.

In Graphics.UI.WXCore.Events:


------------------------------------------------------------------------------------------
    -- Application startup

------------------------------------------------------------------------------------------
    -- | Installs an init handler and starts the event loop.
    -- Note: the closure is deleted when initialization is complete, and
than the Haskell init function
    -- is started.
    appOnInit :: IO () -> IO ()
    appOnInit init
      = do closure  <- createClosure (return () :: IO ()) onDelete (\ev ->
return ())   -- run init on destroy !
           progName <- getProgName
           args     <- getArgs
           argv     <- mapM newCWString (progName:args)
           let argc = length argv
           withArray (argv ++ [nullPtr]) $ \cargv -> wxcAppInitializeC
closure argc cargv
           mapM_ free argv
      where
        onDelete ownerDeleted
          = init

What's going on here?

wxcAppInitializeC sounds pretty hard core.  In
Graphics.UI.WXCore.WxcClassesMZ:

    -- | usage: (@wxcAppInitAllImageHandlers@).
    wxcAppInitAllImageHandlers ::  IO ()
    wxcAppInitAllImageHandlers
      = wx_ELJApp_InitAllImageHandlers
    foreign import ccall "ELJApp_InitAllImageHandlers"
wx_ELJApp_InitAllImageHandlers :: IO ()

    -- | usage: (@wxcAppInitializeC closure argc argv@).
    wxcAppInitializeC :: Closure  a -> Int -> Ptr (Ptr CWchar) ->  IO ()
    wxcAppInitializeC closure _argc _argv
      = withObjectPtr closure $ \cobj_closure ->
        wx_ELJApp_InitializeC cobj_closure  (toCInt _argc)  _argv
    foreign import ccall "ELJApp_InitializeC" wx_ELJApp_InitializeC :: Ptr
(TClosure a) -> CInt -> Ptr (Ptr CWchar) -> IO ()

In wxcore-0.11.1.2/wxc/src/ewxw_main.cpp:

    EWXWEXPORT(void, ELJApp_InitializeC) (wxClosure* closure, int _argc,
char** _argv)
    {
      char* args[] = { "wxc", NULL };

      initClosure = closure;
      if (_argv == NULL) {
        /* note: wxGTK crashes when argv == NULL */
        _argv = args;
        _argc = 1;
      }
      APPTerminating = 0;
      wxEntry(_argc,_argv);
      APPTerminating = 1;
      /* wxPendingEvents is deleted but not set to NULL -> disaster when
restarted from an interpreter */
    #if !defined(WXMAKINGDLL) && !defined(WXUSINGDLL)
      wxPendingEvents = NULL;
    #endif
    #if defined(wxUSE_ODBC) && (wxUSE_ODBC != 0)
      wxDbCloseConnections();
    #endif
    }

(There is also a version for Win32.)

That "disaster" warning sounds relevant.  I didn't know whether the
wxPendingEvents NULLing was in active code, so I added some non-compilable
code in a new #else branch.  Recompilation succeeded, so I gather that the
NULLing is happening.

Next, I added printfs before & after the wxEntry call in
ELJApp_InitializeC.  Sure enough, on the second start, wxEntry is called but
not returned from.

What's initClosure?  The only use I could found is in
wxcore-0.11.1.2/wxc/src/wrapper.cpp:


/*-----------------------------------------------------------------------------
        The main application

-----------------------------------------------------------------------------*/
    wxClosure* initClosure = NULL;

    bool ELJApp::OnInit (void)
    {
      wxInitAllImageHandlers();
      initIdleTimer();
      if (initClosure) {
        delete initClosure; /* special: init is only called once with a NULL
event */
        initClosure=NULL;
      }
      return true;
    }

I see the closure getting deleted but not getting invoked.  Oh, yeah!  The
whole user action has been stuffed into the delete portion of the closure.
The other parts of the closure are inert.


Loose end: there's also ELJApp_InitAllImageHandlers, called by wxHaskell's
'run' (and hence 'start'), defined in wxcore-0.11.1.2/wxc/src/wrapper.cpp:

    EWXWEXPORT(void,ELJApp_InitAllImageHandlers)()
    {
            wxInitAllImageHandlers();
    }

I added printfs before & after the wxInitAllImageHandlers call.  They both
showed up in both start attempts, so I think ELJApp_InitAllImageHandlers is
not a re-start problem.


Where can we go from here?  For instance, are there solutions for other
interpreted settings wxHaskell works, e.g. in Python, Ruby, Lisp or Scheme?

    - Conal

Re: [wxhaskell-users] second "on click" event requires mouse to move

[Eric K. <eri...@gm...>]

Hi Tim,

On Wed, Sep 30, 2009 at 10:07:47 -0700, Tim Sears wrote:
> I am running one of the canonical ball drop examples and I cannot get  
> the "on click" event to fire a second time unless I move the mouse.
> Running mac os x 10.5.8, Haskell Platform, other packages all cabal  
> installed.

Perhaps you'd be able to file a report on the wxHaskell tracker?
  http://sourceforge.net/tracker/?atid=536845&group_id=73133&func=browse

What would be extra helpful is if you could somehow boil this down into
a demonstrator for the bugs/ directory.

Thanks,

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] FindReplaceData Issue

[shelarcy <she...@gm...>]

Pushed. Thanks,

On Thu, 01 Oct 2009 11:05:54 +0900, shelarcy <she...@gm...> wrote:
> On Thu, 01 Oct 2009 06:01:36 +0900, Eric Y. Kow <eri...@gm...> wrote:
>> On Wed, Sep 30, 2009 at 17:59:00 -0300, Fernando Benavides wrote:
>>> I'm attaching the patch because (after just 5'' trying - I'm in my workplace
>>> now :P) I couldn't get darcs send to work.
>>
>> Thanks for being a good sport about this!  Could somebody on the
>> wxHaskell Team take a look at Fernando's patch?
>
> I think this is a reasonable change. So, I'll push his patch after
> trying to build wxHaskell with it.

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] FindReplaceData Issue

[Eric Y. K. <eri...@gm...>]

On Wed, Sep 30, 2009 at 17:59:00 -0300, Fernando Benavides wrote:
> I'm attaching the patch because (after just 5'' trying - I'm in my workplace
> now :P) I couldn't get darcs send to work.

Thanks for being a good sport about this!  Could somebody on the
wxHaskell Team take a look at Fernando's patch?

PS: I'll be getting in touch with you to find out more about the darcs
issue.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] FindReplaceData Issue

[Eric Y. K. <eri...@gm...>]

Hi Fernando,

On Sat, Sep 05, 2009 at 12:17:01 -0300, Fernando Benavides wrote:
> That file has the bug too, indeed

Very sorry for my late response, but would you consider sending a patch?
I seem to remember you managed to fix this by looking into the wxEiffel
version of wxc

  darcs get http://code.haskell.org/wxhaskell
  darcs record
  darcs send

Thanks!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

[wxhaskell-users] second "on click" event requires mouse to move

[Tim S. <ti...@ti...>]

Greetings,
I am running one of the canonical ball drop examples and I cannot get  
the "on click" event to fire a second time unless I move the mouse.
Running mac os x 10.5.8, Haskell Platform, other packages all cabal  
installed.
--Tim

Re: [wxhaskell-users] progress on recabalised wxcore

[Brian L. <br...@lo...>]

On Saturday, 26.09.09 at 06:59, Eric Y. Kow wrote:
> > cabal install
> > --extra-include-dirs=/c/brian/tools/ghc-6.10.4/include/mingw/c++/3.4.5
> > --extra-include-dirs=/c/brian/tools/ghc-6.10.4/include/mingw/c++/3.4.5/mingw32/
> > --extra-include-dirs=/c/SourceCode/Libraries/wxWidgets2.8/contrib/include/
>
> Brian: is there any way we can avoid having to pass those include dirs
> by hand?

I hope so. I will work on this. Thanks.

[wxhaskell-users] progress on recabalised wxcore

[Eric Y. K. <eri...@gm...>]

Hi everyone,

Just a quick note on some recent progress on the wxHaskell
recabalisation.

1. Brian Lewis has joined the wxHaskell team.  I think this will make it
   easier for the wxHaskell crew to complete this work.

2. The work on wxdirect is now on hackage, so those of you who want to
   try out the new wxcore have on less hoop to jump through (it should
   just get picked up automatically when you cabal install in the wxcore
   directory).

3. We're still waiting on the Windows situation to improve before
   merging the work into the darcs repository

4. The below looks like promising progress...

On Tue, Sep 22, 2009 at 20:17:41 -0500, Brian Lewis wrote:
> The Windows version of wx-config was giving us some seemingly unhelpful
> flags, so I changed parseWxConfig in Setup.hs to ignore everything
> except -L, -l, -I, and -D. This did not seem to harm anything in Linux.
> 
> Then I ran
> 
> cabal install
> --extra-include-dirs=/c/brian/tools/ghc-6.10.4/include/mingw/c++/3.4.5
> --extra-include-dirs=/c/brian/tools/ghc-6.10.4/include/mingw/c++/3.4.5/mingw32/
> --extra-include-dirs=/c/SourceCode/Libraries/wxWidgets2.8/contrib/include/
> 
> There were lots of worrisome warnings, but wxcore did seem to install.

Jeremy: do you think maybe we can start from here?

Brian: is there any way we can avoid having to pass those include dirs
by hand?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] weird error linking a wxHaskell-based application [SOLVED!]

[Eric Y. K. <eri...@gm...>]

On Thu, Sep 17, 2009 at 13:34:43 +0100, Eric Kow wrote:
> Any ideas what might be up with this?
> It's wxWidgets installed on MacOS X via MacPorts.

Ah-hah, two mysteries solved in one.

Short answer: we need a small modification in Setup.hs
  http://github.com/kowey/wxcore/commit/5832cec5618b74afc759a3fd7e4ad6318a324b4c

It turns out I had previously complained about this.  Brian suggested
the change but it seemed to have no effect.  A while later, I reported
that wxHaskell was mysteriously working.  I think basically his fix did
work; I must have just been using the wrong wxHaskell.

So if you're having trouble on MacOS with this, try the patch above.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] wxHaskell recabalised

[Eric Y. K. <eri...@gm...>]

On Mon, Sep 07, 2009 at 14:04:30 +0100, Jeremy O'Donoghue wrote:
> Eric, I'll try to get this fixed and turned into darcs patches over the
> next couple of weeks. I agree that it's a very good idea, and although I
> haven't looked in detail, a quick glance suggests that Brian has done a
> very thorough job.
> 
> ... better go off and learn how to use git, I suppose...

Sounds great.  Can I nudge you a bit on this?
It sounds like the two main issues are

 1. getting this into the main repository
 2. figuring out what to do about Windows

Shelarcy, are you around by any chance to look into the #1?

Thanks!

PS.  wxHaskell is looking a little unloved lately, with very little
contact from the team, mails going unmoderated, etc.  Where is
everybody? :-)

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

[wxhaskell-users] weird error linking a wxHaskell-based application

[Eric K. <eri...@gm...>]

Hi Brian,

Any ideas what might be up with this?
It's wxWidgets installed on MacOS X via MacPorts.

Thanks!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] making 'cabal install' just work for MacOS X gui apps

[Eric Y. K. <eri...@gm...>]

Slightly improved version with chmod u+x (oops)

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

[wxhaskell-users] making 'cabal install' just work for MacOS X gui apps

[Eric Y. K. <eri...@gm...>]

Hi everybody,

Attached are a Setup.hs file and a small addendum which you can use to
'cabal install' your wxHaskell apps on MacOS X without having to jump
through any extra hoops like calling the macosx-app script.

Note that the Setup.hs *should* be general enough to just work with your
application, and that it also tries to be clever enough not to do any of
these Mac-specific things outside of OS X.  But please let me know if
you run into any trouble.

Background on
 http://koweycode.blogspot.com/2009/09/cabal-installing-graphical-apps-on.html

Having this is an immense relief as far as scratching itches goes.
Hope it helps somebody else!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] Dynamic events warning message

[Sebastian K. <sk...@gm...>]

2009/9/7 Eric Y. Kow <eri...@gm...>:
> Another thought: are you sure it's your MacPorts-installed wxWidgets
> that's being picked up by the wxcore configure script and not the stock
> one?

You might be right about this. Because i rebuilt wxHaskell again now
to check if it uses the right version of wxWidgets, and it didn't. So
i reinstalled wxWidgets and then built wxHaskell again and now it
works!

Thanks for all the help
Sebastian

[wxhaskell-users] please upgrade wxhaskell repository to darcs hashed

[Eric Y. K. <eri...@gm...>]

Dear wxHaskell hackers:

Fetching wxhaskell via darcs is currently a lot slower than it needs to
be because darcs is forced to (a) fetch every file and (b) perform an
on-the-fly conversion from an old-fashioned repo to a hashed repository.

I would like to convert this repository to the hashed format.  It will
still be using darcs-1 semantics so it will be a perfectly backward
compatible upgrade (if you have a darcs 2 client, you should still be
able to push to the same repository without noticing any changes).

Making this change will speed up the fetch in two ways:
- it will retrieve the pristine cache and patches without having to
  apply them (thanks to hashes, it can trust that your pristine cache
  is correct)
- it allows for lazy fetching via darcs get --lazy

This upgrade will require anybody fetching darcs to have a darcs 2
client, but I believe darcs 2 is now sufficiently widespread that you
can afford this.  Besides: haskellers can just do cabal install darcs.

To do this upgrade:

 darcs get --hashed /srv/code/wxhaskell wxhaskell.hashed
 cp -R wxhaskell.hashed/_darcs /srv/code/wxhaskell/_darcs-hashed
 cd /srv/code/wxhaskell
 cp _darcs/prefs/defaults _darcs-hashed/prefs
 mv _darcs _darcs-old
 mv _darcs-hashed _darcs
 rm -rf _darcs-old

Future versions of darcs will include a optimize --upgrade command
to simplify this procedure, but no need to hang around waiting :-)

What do you say?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] wxHaskell recabalised

[Eric Y. K. <eri...@gm...>]

On Mon, Sep 07, 2009 at 14:04:30 +0100, Jeremy O'Donoghue wrote:
> > Until we hear back from the wxHaskell team, work on wxcore is taking
> > place on github.  If the team respond, I think we should start
> > submitting patches so that the wxHaskell darcs repository catches up.
> >   
> Eric, I'll try to get this fixed and turned into darcs patches over the
> next couple of weeks. I agree that it's a very good idea, and although I
> haven't looked in detail, a quick glance suggests that Brian has done a
> very thorough job.

Thanks! I've sent a very small fragment of Brian's work (not the bits
that matter, unfortunately) to wxhaskell-devel but they got stuck in the
moderation queue.

Also: I'd like to help you guys with darcs a little bit, but I'll talk
about that in a separate mail.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] wxHaskell recabalised

[Jeremy O'D. <jer...@gm...>]

Eric Y. Kow wrote:
> For the moment, you need both git and darcs.
>
> Until we hear back from the wxHaskell team, work on wxcore is taking
> place on github.  If the team respond, I think we should start
> submitting patches so that the wxHaskell darcs repository catches up.
>   
Eric, I'll try to get this fixed and turned into darcs patches over the
next couple of weeks. I agree that it's a very good idea, and although I
haven't looked in detail, a quick glance suggests that Brian has done a
very thorough job.

... better go off and learn how to use git, I suppose...

Regards
Jeremy