wxhaskell-devel — wxhaskell developers

Re: [wxhaskell-devel] SourceForge project

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

Hi list

On 4 October 2011 01:55, Dave Tapley <duk...@gm...> wrote:

> Hi all, would someone like to add me (davetapley) to the
> SourceForge.net project.
> It doesn't look like there has been much activity on it, I assume this
> is just through lack of interest/development, and not because we've
> moved somewhere else?
>

I have added Dave to the SF project, so no need for anyone else to worry.

Jeremy

[wxhaskell-devel] SourceForge project

[Dave T. <duk...@gm...>]

Hi all, would someone like to add me (davetapley) to the
SourceForge.net project.
It doesn't look like there has been much activity on it, I assume this
is just through lack of interest/development, and not because we've
moved somewhere else?

I'd like to start looking at getting OpenGL support back in, and I
thought I might as well pick up this[1] ticket if I'm going to do so.

Thanks,
Dave

[1] https://sourceforge.net/tracker/?func=detail&atid=536848&aid=2992082&group_id=73133

Re: [wxhaskell-devel] Wrapping wxAny

[Dave T. <duk...@gm...>]

Hi all, I'm still struggling along with this.
I've summarised my current problem here: http://hpaste.org/51854

If any of you would be kind enough to take a look.

Dave,


On 27 September 2011 21:05, Dave Tapley <duk...@gm...> wrote:
> Hi all, I've spent a few hours now trying to wrap the wxAny class, I
> just wondered if anyone had given any thought to this (or it's 2.8
> predecessor: wxVariant) already?
>
> It's needed because I'm wrapping this functionality:
> http://docs.wxwidgets.org/2.9.2/classwx_property_grid_event.html#577d7fb277be169e295726878dcbb7db
> (wxVariant is automatically promoted to the preferred wxAny in 2.9)
>
> Dave,
>

[wxhaskell-devel] Wrapping wxAny

[Dave T. <duk...@gm...>]

Hi all, I've spent a few hours now trying to wrap the wxAny class, I
just wondered if anyone had given any thought to this (or it's 2.8
predecessor: wxVariant) already?

It's needed because I'm wrapping this functionality:
http://docs.wxwidgets.org/2.9.2/classwx_property_grid_event.html#577d7fb277be169e295726878dcbb7db
(wxVariant is automatically promoted to the preferred wxAny in 2.9)

Dave,

Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

[Dave T. <duk...@gm...>]

On 20 September 2011 20:57, Dave Tapley <duk...@gm...> wrote:
> Hi Eric,
>
> Am I correct in recalling that you did some of the work to get wxHaskell
> supporting unicode?
>
> I've using wxHaskell with wxWidgets 2.9.2 (the latest development release)
> and it seems that any attempt to get back a wxString in Haskell code will
> result in a "Prelude.chr: bad argument:" crash at run time; I've verified
> that the same code works correctly with wxWidgets 2.8.
>
> A good example is ./samples/wx/ListCtrl.hs, you will get the crash when you
> click on an item in the list.
>
> Now the good news is that this is almost certainly related to the changes to
> unicode handling in wxWidgets:
> http://docs.wxwidgets.org/2.9/overview_changes_since28.html
>
> But I thought I'd send out a message asking for a sanity check before I get
> too busy working on fixing it.
>
> Dave,
>

Good news everyone!
This is fixed, at least for GTK2 with wx-2.9, I don't know if it
breaks building against previous versions, perhaps someone would like
to find out?

Dave,
Patch attached.

Re: [wxhaskell-devel] Compile time for wxcore

[Dave T. <duk...@gm...>]

On 21 September 2011 21:02, Dave Tapley <duk...@gm...> wrote:
> On 21 September 2011 17:33, Jeremy O'Donoghue
> <jer...@gm...> wrote:
>> Hi Dave,
>>
>> On 20 September 2011 17:58, Dave Tapley <duk...@gm...> wrote:
>>>
>>> On 16 September 2011 23:30, Dave Tapley <duk...@gm...> wrote:
>>>>
>>>> I presume everyone has a very long compile time when building wxcore?
>>>> Specifically rebuilding everything under src/cpp/ every time..
>>>>
>>>> Has anyone ever looked into avoiding this complete rebuild?
>>>
>>> I've just spent a few hours looking deeper in to this and come across two
>>> issues:
>>>
>>> 1. There is a very informative blog post[1] written by Jeremy, which deals
>>> with the subject of "Compiling C or C++ code from within Cabal".
>>> Unfortunately I can't find any of the code mentioned in the post in the
>>> project, specifically I tried to find a "myBuildHook" in "./wxcore/Setup.hs"
>>> (I also looked in previous revisions using a trackdown grep[2]) but I didn't
>>> find anything. Perhaps someone with better knowledge of the project can
>>> comment on if/where/when the code in the post was used?
>>
>> The code sits on my development machine. It works, but with a fairly serious
>> limitation.
>>
>> The limitation is that I do not do any dependency tracking. It works by
>> checking if an object file is older than its corresponding source file. This
>> works fine for .cpp files but breaks if you change a header. Short of
>> writing a complete dependency tracker, this is hard to fix, and in truth I
>> think it belongs in Cabal.
>>
>> If Cabal wants to say that it can compile C/C++ code, it should be the one
>> to do so correctly, especially as dependency tracking for C/C++ is vile and
>> compiler dependent(*).
>
> Firstly welcome back, and thanks for taking the time to reply :)
>
> Ah, this all makes more sense now.
> Do you know if there is any documentation on cabal's C/C++ compiling abilities?
> I still have no idea how the "confHook" stuff actually results in code
> being built, because I don't see any reference to the C++ code (i.e.
> wxcore/src/cpp/) in Setup.hs, only the calling of 'wxdirect' to
> generate them, and use of 'libBuildInfo' to set up GCC.
>
>>
>> I would be very happy to put the code out there as a GitHub gist or similar
>> - it's only in one or two files, and quite easy to follow, but I don't feel
>> it is ready for prime time due to the limitations noted above.
>
> Well, for me, the compile time of the C++ component is around four
> minutes, which proves to be a real pain when you miss one semi-colon.
> I'd certainly like to give your code a go, and I shall do so whilst
> heeding your warning :)
>
>>
>> (*) one option might be to do this only for GCC, as in practice we only
>> really support GCC anyway.
>>
>>> 2. Inspecting the wxdirect code you can see that "System.IO.writeFile" is
>>> used to write all the generated code[3], but no test is performed to see if
>>> the output file has actually changed. Thus the file is always opened for
>>> write, and so its modification time is changed, and so everything is
>>> recompiled every time wxcore is built. I have have written a local patch
>>> which replaces the "writeFile" function with one which first checks whether
>>> the string to be written differs (aside from date/time stamp) to the current
>>> one; it only performs the "writeFile" if there has been a change.
>>> Using this patch none of the Haskell code is re-built, but unfortunately
>>> all the C++ code is.
>>
>> This is a nice patch - I think we should apply it.
>
> Excellent, well at the moment it's a rather 'quick' implementation,
> comprising of the following function:
> writeFileIfRequired :: FilePath -> String -> IO ()
> writeFileIfRequired f str = readFile f >>= evaluate >>= \str' -> when
> (not $ and $ zipWith isSame (lines str) (lines str')) (writeFile f
> str)
>    where isSame l1 l2 = ("UTC" `isInfixOf` l1) || ("UTC" `isInfixOf`
> l2) || (l1 == l2)
>
> You'll note the the use of ("UTC" `isInfixOf`), this is my nasty hack
> to get around the fact that the time of generation is written in to
> the file, and this obviously changes every time. Unless anyone has a
> good reason not to, I'd like to suggest we remove this "generated
> on..." lines (but leave in the "don't edit this" blurb), if someone
> really wants to know they can always check the file modification time?
>
> Dave,
>
>>
>> Jeremy
>>
>

Hmm, I was just revisiting this and happened on the following:

The Setup.hs for wxcore uses "simpleUserHooks", overriding only "confHook".
However there is also "cleanHook", which is defined by simpleUserHooks to be:
  cleanHook = \p _ _ f -> clean p f,

If you consult the source for clean[1] you'll see that it tries to
"remove the whole dist/ directory rather than tracking exactly what
files we created in there". I presume that's why we have to do a full
re-build every time?

To try and circumvent this I modified the definition of "main" in
Setup.hs to this:
main = defaultMainWithHooks simpleUserHooks { confHook = myConfHook,
cleanHook = (\_ _ _ _ -> return ())}

Unfortunately it still seems to re-build all the C++ on each 'install'
from cabal.
Not sure why?

Dave,


[1] Taken from http://www.haskell.org/ghc/docs/6.10.4/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks
-- Cleaning

clean :: PackageDescription -> CleanFlags -> IO ()
clean pkg_descr flags = do
    let distPref = fromFlag $ cleanDistPref flags
    notice verbosity "cleaning..."

    maybeConfig <- if fromFlag (cleanSaveConf flags)
                     then maybeGetPersistBuildConfig distPref
                     else return Nothing

    -- remove the whole dist/ directory rather than tracking exactly what files
    -- we created in there.
    chattyTry "removing dist/" $ do
      exists <- doesDirectoryExist distPref
      when exists (removeDirectoryRecursive distPref)

    -- these live in the top level dir so must be removed separately
    removeRegScripts

    -- Any extra files the user wants to remove
    mapM_ removeFileOrDirectory (extraTmpFiles pkg_descr)

    -- If the user wanted to save the config, write it back
    maybe (return ()) (writePersistBuildConfig distPref) maybeConfig

  where
        removeFileOrDirectory :: FilePath -> IO ()
        removeFileOrDirectory fname = do
            isDir <- doesDirectoryExist fname
            isFile <- doesFileExist fname
            if isDir then removeDirectoryRecursive fname
              else if isFile then removeFile fname
              else return ()
        verbosity = fromFlag (cleanVerbosity flags)

Re: [wxhaskell-devel] Patch review, testing, and submission

[Dave T. <duk...@gm...>]

On 22 September 2011 09:54, Jeremy O'Donoghue
<jer...@gm...> wrote:
> Hi list,
>
> On 21 September 2011 21:58, Dave Tapley <duk...@gm...> wrote:
>>
>> Hi -devel,
>>
>> As I've alluded to before I have a fairly large number of local
>> patches (mostly gtk/2.9 fixes) in my local darcs repo.
>> I think it makes sense to get these on to code.haskell.org at some point.
>> The good news is I've been fairly meticulous in ensuring each patch is
>> encapsulated and has a reasonable commit message, the bad news is that
>> I've only been testing with wx-2.9.2 and GTK, so my patches will
>> probably break other configurations.
>
>
>>
>> Firstly, is it worth us setting up an approval queue of some form,
>> ideally with people on a few different configurations?
>> Secondly, who has write access for http://code.haskell.org/wxhaskell/ ?
>
> At least Eric, Shelarcy and I, probably a few others. If you have an account
> on code.haskell.org it is trivial to add you as a committer.

I'm not on code.haskell.org at the moment, but I'll look in to it.

>
> I would suggest that we perhaps set up a wxWidgets > 2.9 repo on darcsden or
> patch-tag (with caveat that I had a lot of trouble getting my Windows box to
> talk to darcsden - perhaps I should revisit this).
>
> The new patches go into the development repo with a lightweight review
> process (the bar for submission should be that one of the group of
> committers has compiled and tested on at least one target). We could perhaps
> have occasional (e.g. bi-weekly) freezes where we stabilize existing code on
> all platforms before moving on.
>
> For the new codebase we explicitly disallow support for older wxWidgets, to
> get rid of non target-related conditional compilation. We also allow API
> changes, since a few places we have retained older APIs calling the
> replacement functions. This is tricky for users of wxcore as they can't look
> up the function in the wxWidgets documentation, and most wxcore
> documentation is very sparse (just type info).

I'm fully in support of this.
I'll be happy to test on Linux/GTK2, I could test Windows as well, but
I don't have any development environment set up, so it might be easier
for someone else to do it.

I'd also like to put myself forward to write some kind of automated
functional test suite. Right now I'm thinking of something as simple
as a script to compile everything below ./samples and then execute and
terminate each one in turn; perhaps parsing stdout/stderr/exit-codes
and printing out a report.
That should allow people to quickly identify problems on their
platform when we have a code freeze.

Dave,

>
> We should have another person (I suggest me for this one) who looks at the
> patches on the new version and back-ports those which are relevant to older
> wxHaskell versions to the code.haskell.org repo - in other words, older
> wxHaskell goes into a pure maintenance mode with no new features.

That's good of you to suggest yourself for that.
It might be interesting to see how many people we have actually using
wxHaskell from cabal (I wonder if hackage can tell us how many pulls
it has per month?), to decide how much effort goes in to backports.

>
> How does this approach sound? We currently suffer because development
> essentially takes place on the mainline, so large changes destabilize code
> which we depend on to make releases. I would like to address this.

+1 from myself.

Dave,

>
> Best regards
> Jeremy
>

Re: [wxhaskell-devel] Patch review, testing, and submission

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

Hi list,

On 21 September 2011 21:58, Dave Tapley <duk...@gm...> wrote:

> Hi -devel,
>
> As I've alluded to before I have a fairly large number of local
> patches (mostly gtk/2.9 fixes) in my local darcs repo.
> I think it makes sense to get these on to code.haskell.org at some point.
> The good news is I've been fairly meticulous in ensuring each patch is
> encapsulated and has a reasonable commit message, the bad news is that
> I've only been testing with wx-2.9.2 and GTK, so my patches will
> probably break other configurations.
>


> Firstly, is it worth us setting up an approval queue of some form,
> ideally with people on a few different configurations?
> Secondly, who has write access for http://code.haskell.org/wxhaskell/ ?
>

At least Eric, Shelarcy and I, probably a few others. If you have an account
on code.haskell.org it is trivial to add you as a committer.

I would suggest that we perhaps set up a wxWidgets > 2.9 repo on darcsden or
patch-tag (with caveat that I had a lot of trouble getting my Windows box to
talk to darcsden - perhaps I should revisit this).

The new patches go into the development repo with a lightweight review
process (the bar for submission should be that one of the group of
committers has compiled and tested on at least one target). We could perhaps
have occasional (e.g. bi-weekly) freezes where we stabilize existing code on
all platforms before moving on.

For the new codebase we explicitly disallow support for older wxWidgets, to
get rid of non target-related conditional compilation. We also allow API
changes, since a few places we have retained older APIs calling the
replacement functions. This is tricky for users of wxcore as they can't look
up the function in the wxWidgets documentation, and most wxcore
documentation is very sparse (just type info).

We should have another person (I suggest me for this one) who looks at the
patches on the new version and back-ports those which are relevant to older
wxHaskell versions to the code.haskell.org repo - in other words, older
wxHaskell goes into a pure maintenance mode with no new features.

How does this approach sound? We currently suffer because development
essentially takes place on the mainline, so large changes destabilize code
which we depend on to make releases. I would like to address this.

Best regards
Jeremy

[wxhaskell-devel] Patch review, testing, and submission

[Dave T. <duk...@gm...>]

Hi -devel,

As I've alluded to before I have a fairly large number of local
patches (mostly gtk/2.9 fixes) in my local darcs repo.
I think it makes sense to get these on to code.haskell.org at some point.
The good news is I've been fairly meticulous in ensuring each patch is
encapsulated and has a reasonable commit message, the bad news is that
I've only been testing with wx-2.9.2 and GTK, so my patches will
probably break other configurations.

Firstly, is it worth us setting up an approval queue of some form,
ideally with people on a few different configurations?
Secondly, who has write access for http://code.haskell.org/wxhaskell/ ?

Dave,

Re: [wxhaskell-devel] Compile time for wxcore

[Dave T. <duk...@gm...>]

On 21 September 2011 17:33, Jeremy O'Donoghue
<jer...@gm...> wrote:
> Hi Dave,
>
> On 20 September 2011 17:58, Dave Tapley <duk...@gm...> wrote:
>>
>> On 16 September 2011 23:30, Dave Tapley <duk...@gm...> wrote:
>>>
>>> I presume everyone has a very long compile time when building wxcore?
>>> Specifically rebuilding everything under src/cpp/ every time..
>>>
>>> Has anyone ever looked into avoiding this complete rebuild?
>>
>> I've just spent a few hours looking deeper in to this and come across two
>> issues:
>>
>> 1. There is a very informative blog post[1] written by Jeremy, which deals
>> with the subject of "Compiling C or C++ code from within Cabal".
>> Unfortunately I can't find any of the code mentioned in the post in the
>> project, specifically I tried to find a "myBuildHook" in "./wxcore/Setup.hs"
>> (I also looked in previous revisions using a trackdown grep[2]) but I didn't
>> find anything. Perhaps someone with better knowledge of the project can
>> comment on if/where/when the code in the post was used?
>
> The code sits on my development machine. It works, but with a fairly serious
> limitation.
>
> The limitation is that I do not do any dependency tracking. It works by
> checking if an object file is older than its corresponding source file. This
> works fine for .cpp files but breaks if you change a header. Short of
> writing a complete dependency tracker, this is hard to fix, and in truth I
> think it belongs in Cabal.
>
> If Cabal wants to say that it can compile C/C++ code, it should be the one
> to do so correctly, especially as dependency tracking for C/C++ is vile and
> compiler dependent(*).

Firstly welcome back, and thanks for taking the time to reply :)

Ah, this all makes more sense now.
Do you know if there is any documentation on cabal's C/C++ compiling abilities?
I still have no idea how the "confHook" stuff actually results in code
being built, because I don't see any reference to the C++ code (i.e.
wxcore/src/cpp/) in Setup.hs, only the calling of 'wxdirect' to
generate them, and use of 'libBuildInfo' to set up GCC.

>
> I would be very happy to put the code out there as a GitHub gist or similar
> - it's only in one or two files, and quite easy to follow, but I don't feel
> it is ready for prime time due to the limitations noted above.

Well, for me, the compile time of the C++ component is around four
minutes, which proves to be a real pain when you miss one semi-colon.
I'd certainly like to give your code a go, and I shall do so whilst
heeding your warning :)

>
> (*) one option might be to do this only for GCC, as in practice we only
> really support GCC anyway.
>
>> 2. Inspecting the wxdirect code you can see that "System.IO.writeFile" is
>> used to write all the generated code[3], but no test is performed to see if
>> the output file has actually changed. Thus the file is always opened for
>> write, and so its modification time is changed, and so everything is
>> recompiled every time wxcore is built. I have have written a local patch
>> which replaces the "writeFile" function with one which first checks whether
>> the string to be written differs (aside from date/time stamp) to the current
>> one; it only performs the "writeFile" if there has been a change.
>> Using this patch none of the Haskell code is re-built, but unfortunately
>> all the C++ code is.
>
> This is a nice patch - I think we should apply it.

Excellent, well at the moment it's a rather 'quick' implementation,
comprising of the following function:
writeFileIfRequired :: FilePath -> String -> IO ()
writeFileIfRequired f str = readFile f >>= evaluate >>= \str' -> when
(not $ and $ zipWith isSame (lines str) (lines str')) (writeFile f
str)
    where isSame l1 l2 = ("UTC" `isInfixOf` l1) || ("UTC" `isInfixOf`
l2) || (l1 == l2)

You'll note the the use of ("UTC" `isInfixOf`), this is my nasty hack
to get around the fact that the time of generation is written in to
the file, and this obviously changes every time. Unless anyone has a
good reason not to, I'd like to suggest we remove this "generated
on..." lines (but leave in the "don't edit this" blurb), if someone
really wants to know they can always check the file modification time?

Dave,

>
> Jeremy
>

Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

[Dave T. <duk...@gm...>]

On 21 September 2011 15:29, eric.kow <eri...@gm...> wrote:
>
> On Tue, Sep 20, 2011 at 20:57:37 +0100, Dave Tapley wrote:
> > Am I correct in recalling that you did some of the work to get wxHaskell
> > supporting unicode?
>
> That's right.  Mostly swapping char with w_char
>
> > Now the good news is that this is almost certainly related to the changes to
> > unicode handling in wxWidgets:
> > http://docs.wxwidgets.org/2.9/overview_changes_since28.html
>
> Ouch, seems to make sense.
>
> Was dimly aware that wxWidgets 3.0 would be changing the string type but
> I guess I let wishful thinking fool me into thinking it didn't affect
> wxWidgets 2.9 (not really paying enough attention to the numbering)
>
> --
> Eric Kow <http://erickow.com>

Some more updates on this..
Presuming that the Prelude.chr error was due to some unicode
shenanigans I built wx 2.9.2 with --disable-unicode (so "wx-config
--list" now reports that "Default config is gtk2-ansi-2.9".
After doing so I tried to recompile wx and wxcore against,
unfortunately we now get a bunch of compilation errors of this form:
src/cpp/eljdnd.cpp:222:0:
    error: cannot convert ‘wchar_t*’ to ‘const wxChar*’ in assignment

I figured with makes sense (although I'm not sure why it wasn't an
issue when building against 2.8) when you look at line 222:
    ((const wxChar**)_lst)[i] = wxStrdup (arr.Item(i).wchar_str());

In 2.9.2 that call to 'wchar_str' is documented as: "Returns an object
with string data that is implicitly convertible to char* pointer"[1],
that doesn't sound that bad. If you look at 'char_str'[2] it has the
same documentation *but* it has a default parameter (const wxMBConv &
conv = wxConvLibc), I rather hoped that 'conv' object would take care
of everything, and so I changed all the 'wchar_str()'s into
'char_str()'s (and I've attached a patch with that done).

The good news is it now compiles successfully, and the Prelude.chr
error has gone away, but now we only get the first character of every
string displayed. This leads me to think that the 'conv' object isn't
doing its job properly, perhaps because 'wxConvLibc' isn't set
correctly?

Dave,

[1] http://docs.wxwidgets.org/2.9/classwx_string.html#3d9337b865b8962e172c2589409c6876
[2] http://docs.wxwidgets.org/2.9/classwx_string.html#edcaea87fc347a940263a533bd56846f

Re: [wxhaskell-devel] Modified example ImageViewer.hs

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

On Wed, Sep 21, 2011 at 20:20:27 +0200, David Virebayre wrote:
> 2011/9/21 Eric Y. Kow <eri...@gm...>:
> 
> > I'd split the cleanup patches (like adding a type signature to existing
> > stuff) from the new feature patches, but you can send them all in one
> > bundle
> 
> Ok so this is where I don't know how to do it.

> Let's say I take the time to learn how to re-record it cleanly, what
> do I do next ?

Are you talking about sending the patches?

You want to use the darcs send command.

- You need a working sendmail command. 
- You use it like you would use darcs push.
- You can send patches to any darcs repository URL or filepath

Try in order:

- darcs help send
- the manual
- http://wiki.darcs.net/Using/Send for some practical supplementary tips

Let me know if you need any specific help

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] I need help setting up

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

On Wed, Sep 21, 2011 at 17:30:13 +0200, David Virebayre wrote:
> the darcs get was suspiciouly fast.

Files from modern (hashed) darcs repositories are cached, which
may be why you are seeing this.

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] Modified example ImageViewer.hs

[David V. <dav...@gm...>]

2011/9/21 Eric Y. Kow <eri...@gm...>:

> I'd split the cleanup patches (like adding a type signature to existing
> stuff) from the new feature patches, but you can send them all in one
> bundle

Ok so this is where I don't know how to do it.

When I modified Imageviewer.hs, I recorded separately the cleanup and
new feature patches using darcs, but :
When trying to build a version of wxwidgets so I can maybe help
contribute, I deleted my wxhaskell directory (doh) to get a fresh
version... Losing my modifications and the history.

I can get ImageViewer.hs back since I sent it to the list, but I lost
the history.

Let's say I take the time to learn how to re-record it cleanly, what
do I do next ?

David.

Re: [wxhaskell-devel] I need help setting up

[Dave T. <duk...@gm...>]

On 21 September 2011 16:30, David Virebayre <dav...@gm...>wrote:

> Bonjour,
>
> > Ah! Yes! I had error too, but I can't remember how I resolved it, which
> > makes me think I might have just cleaned everything up and started afresh
> > (just with the modified library list);  have you tried that?
>
> I'm not sure I did this right, but I deleted my wxhaskell directory,
> issued a darcs get, changed wxcore/Setup.hs again, and re-tried
> cabal-dev
>
> Same result.
>
> the darcs get was suspiciouly fast.
>
> David
>

Aha, I did do something to fix this!
Here's my 'probably breaks other things but hasn't caused me a problem as of
yet' fix:
(I really need to start getting all my local patches reviewed and pushed to
code.haskell.org..)

[wxEventType is an extern type in wxWidgets 2.9.2
duk...@gm...**20110729050251
 Ignore-this: a709f60a95638a6ae87b570dc7d1072d
 Compare wxEventType in include/wx/event.h in wxWidgets 2.8.10 and 2.9.2,
 you will see that the latter contains the lines:
     extern WXDLLIMPEXP_BASE const wxEventType wxEVT_NULL;
     extern WXDLLIMPEXP_BASE const wxEventType wxEVT_FIRST;
 This was causing a "Conflicting exports" error as detailed here:
 http://sourceforge.net/mailarchive/message.php?msg_id=27810904
 Because wxc_glue.h previously exported these as ints.
] hunk ./wxcore/src/include/wxc_glue.h 18
-int expEVT_NULL();^M$
-int expEVT_FIRST();^M$

Re: [wxhaskell-devel] Compile time for wxcore

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

Hi Dave,

On 20 September 2011 17:58, Dave Tapley <duk...@gm...> wrote:

> On 16 September 2011 23:30, Dave Tapley <duk...@gm...> wrote:
>
>> I presume everyone has a very long compile time when building wxcore?
>> Specifically rebuilding everything under src/cpp/ every time..
>>
>> Has anyone ever looked into avoiding this complete rebuild?
>>
>
> I've just spent a few hours looking deeper in to this and come across two
> issues:
>
> 1. There is a very informative blog post[1] written by Jeremy, which deals
> with the subject of "Compiling C or C++ code from within Cabal".
> Unfortunately I can't find any of the code mentioned in the post in the
> project, specifically I tried to find a "myBuildHook" in "./wxcore/Setup.hs"
> (I also looked in previous revisions using a trackdown grep[2]) but I didn't
> find anything. Perhaps someone with better knowledge of the project can
> comment on if/where/when the code in the post was used?
>

The code sits on my development machine. It works, but with a fairly serious
limitation.

The limitation is that I do not do any dependency tracking. It works by
checking if an object file is older than its corresponding source file. This
works fine for .cpp files but breaks if you change a header. Short of
writing a complete dependency tracker, this is hard to fix, and in truth I
think it belongs in Cabal.

If Cabal wants to say that it can compile C/C++ code, it should be the one
to do so correctly, especially as dependency tracking for C/C++ is vile and
compiler dependent(*).

I would be very happy to put the code out there as a GitHub gist or similar
- it's only in one or two files, and quite easy to follow, but I don't feel
it is ready for prime time due to the limitations noted above.

(*) one option might be to do this only for GCC, as in practice we only
really support GCC anyway.

2. Inspecting the wxdirect code you can see that "System.IO.writeFile" is
> used to write all the generated code[3], but no test is performed to see if
> the output file has actually changed. Thus the file is always opened for
> write, and so its modification time is changed, and so everything is
> recompiled every time wxcore is built. I have have written a local patch
> which replaces the "writeFile" function with one which first checks whether
> the string to be written differs (aside from date/time stamp) to the current
> one; it only performs the "writeFile" if there has been a change.
> Using this patch none of the Haskell code is re-built, but unfortunately
> all the C++ code is.
>

This is a nice patch - I think we should apply it.

Jeremy

Re: [wxhaskell-devel] Strings reduced to 1 letter on windows, on a program that otherwise works well on linux

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

Hi David,

On 21 September 2011 16:49, David Virebayre <dav...@gm...>wrote:

> Bonjour,
>
> I'm posting this hoping that someone has seen the same problem; if
> nobody has, I'll make an example program, post the source and give
> screenshots.
>
> I have a program that works fine on linux.
>
> I followed the instructions to install wxhaskell on windows, all went
> fine. it's with wxWidgets 2.8.10.
>
> I compiled the source on windows, and when I run the program, all the
> strings are reduced to the first character: Labels in buttons, text
> fields, name of the app's icon (which fire an error because the icon
> doesn't exist) etc...
>
> Anyone has seen this before ?
>

This sounds like a Unicode problem.

On Windows, strings are natively encoded in UTF16, which uses two bytes to
represent a character. In the common case (for Western European languages),
most characters have the upper byte set to zero (as the codes used are
backwards compatible with ASCII).

Now, older wxWidgets (anything < wxWidgets 2.9) can be built as Unicode
(where Strings are represented as wchar_t *) or ASCII (where strings are a C
char*) - a feature to enable wxWidgets to wrap older code which believes
that only Western European languages should be able to be expressed ;-)

I would start by checking the wxWidgets libraries you are linking. If you
have wxmswu<something> then it's Unicode - otherwise it is ASCII.

Because of the coding, the ASCII wxWidgets libraries see the '0' as the
upper byte of a Unicode string as a string terminator.

Regards
Jeremy

Re: [wxhaskell-devel] Modified example ImageViewer.hs

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

On Fri, Sep 16, 2011 at 22:52:51 +0200, D.V. wrote:
> So here's a quickly modified ImageViewer.hs. It's not a big change !
> 
> I'd like someone to review the changes before I send a patch, please.

Didn't look too carefully, but seems to make sense.

Sounds like it'd be a good way to help for folks who are just starting
to contribute to wxHaskell (and thanks btw, from a grateful
wxhaskell-user)

I'd split the cleanup patches (like adding a type signature to existing
stuff) from the new feature patches, but you can send them all in one
bundle

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] I need help setting up

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

I wanted to add one thing to this very useful thread, if only to have a
record of it somewhere:

On 17 September 2011 18:33, Dave Tapley <duk...@gm...> wrote:

> For the curious:
> Wondering how the library can still compile with some includes missing?
> (I believe, perhaps someone can confirm...)
> If you inspect some of the .cpps under wxcore/src/cpp/ you'll find they do
> a bunch of ifdefs (for example ifdef wxUSE_MEDIACTRL).
> Where do these defines come from?
> Well in Setup.hs you'll find this:
> >  (readProcess "wx-config" ["--libs", "--cppflags"] "")
> And that "cppflags" flag will print out (or in our case, on Linux, not
> print out) things like (wxUSE_MEDIACTRL), these are passed to "ccOptions"
> (from Distribution.InstalledPackageInfo), and the build system then passes
> these to the CPP linker.
>

There is a horrible hack in the way this is implemented, which is that
wxhaskell actually compiles stub code for all of the APIs for which you
don't have the required library, and has the functions return 'benign'
(usually NULL) values.

I have never liked this - it is down to the fact that wxdirect doesn't
handle the preprocessor, so you cannot put conditional compilation in the
core wxC headers. Yet another item for the TODO list.

Jeremy

Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

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

On Wed, Sep 21, 2011 at 17:44:58 +0200, David Virebayre wrote:
> I have no good answer to those questions. But, if I didn't read too
> fast, I think wxwidgets uses UTF-16, which is also what is used in
> Text.

There is a GSoC project to switch Text to to UTF-8 for what it's worth

> I've made a little program and used Text to process Textual data which
> I want to display in a GUI, so converting to String puts lots of
> unwanted T.unpack here and there.

OK so that's potentially an argument about convenience

> Since wxHaskell or wxWidgets probably has to convert that back to
> UTF-16 at some point...
> 
> I'm probably thinking way ahead of time with this idea.

Being a sort of naive computers-dont-really-exist-only-code-does
sort, I'd tend to say this is an implementation detail we shouldn't
think too too hard about.  Just make it work first.

-- 
Eric Kow <http://erickow.com>

[wxhaskell-devel] Strings reduced to 1 letter on windows, on a program that otherwise works well on linux

[David V. <dav...@gm...>]

Bonjour,

I'm posting this hoping that someone has seen the same problem; if
nobody has, I'll make an example program, post the source and give
screenshots.

I have a program that works fine on linux.

I followed the instructions to install wxhaskell on windows, all went
fine. it's with wxWidgets 2.8.10.

I compiled the source on windows, and when I run the program, all the
strings are reduced to the first character: Labels in buttons, text
fields, name of the app's icon (which fire an error because the icon
doesn't exist) etc...

Anyone has seen this before ?

David.

Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

[David V. <dav...@gm...>]

2011/9/21 Eric Y. Kow <eri...@gm...>:
> On Wed, Sep 21, 2011 at 16:36:55 +0200, David Virebayre wrote:
>> I have a probably stupid question, but I'll fire it anyways:
>
> Hmm, worth a thought.
>
>> Would it make sense to have future versions of wxHaskell support Text
>> instead of String ?
>
> Do GUIs typically manipulate large text fields for which this would make
> sense?  Is String a source of overhead for any other reason (ie. lots of
> text fields)?  Do we care if we just of lots of small ones?  Is this a
> matter of convenience for people moving to using a lot more Text in
> modern Haskell?

I have no good answer to those questions. But, if I didn't read too
fast, I think wxwidgets uses UTF-16, which is also what is used in
Text.

I've made a little program and used Text to process Textual data which
I want to display in a GUI, so converting to String puts lots of
unwanted T.unpack here and there.

This is annoying enough that I wish I didn't use Text to begin with !
I think it's bad because
- Text is in the Haskell Platform, so it's the blessed way of dealing
with text data
- Takes less memory, faster, etc
- Not using it would slow its adoption

Since wxHaskell or wxWidgets probably has to convert that back to
UTF-16 at some point...

I'm probably thinking way ahead of time with this idea.

David.

>
> --
> Eric Kow <http://erickow.com>
>

Re: [wxhaskell-devel] I need help setting up

[David V. <dav...@gm...>]

Bonjour,

> Ah! Yes! I had error too, but I can't remember how I resolved it, which
> makes me think I might have just cleaned everything up and started afresh
> (just with the modified library list);  have you tried that?

I'm not sure I did this right, but I deleted my wxhaskell directory,
issued a darcs get, changed wxcore/Setup.hs again, and re-tried
cabal-dev

Same result.

the darcs get was suspiciouly fast.

David

Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

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

On Wed, Sep 21, 2011 at 16:36:55 +0200, David Virebayre wrote:
> I have a probably stupid question, but I'll fire it anyways:

Hmm, worth a thought.

> Would it make sense to have future versions of wxHaskell support Text
> instead of String ?

Do GUIs typically manipulate large text fields for which this would make
sense?  Is String a source of overhead for any other reason (ie. lots of
text fields)?  Do we care if we just of lots of small ones?  Is this a
matter of convenience for people moving to using a lot more Text in
modern Haskell?

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

[David V. <dav...@gm...>]

I have a probably stupid question, but I'll fire it anyways:

Would it make sense to have future versions of wxHaskell support Text
instead of String ?

David.

2011/9/21 eric.kow <eri...@gm...>:
> On Tue, Sep 20, 2011 at 20:57:37 +0100, Dave Tapley wrote:
>> Am I correct in recalling that you did some of the work to get wxHaskell
>> supporting unicode?
>
> That's right.  Mostly swapping char with w_char
>
>> Now the good news is that this is almost certainly related to the changes to
>> unicode handling in wxWidgets:
>> http://docs.wxwidgets.org/2.9/overview_changes_since28.html
>
> Ouch, seems to make sense.
>
> Was dimly aware that wxWidgets 3.0 would be changing the string type but
> I guess I let wishful thinking fool me into thinking it didn't affect
> wxWidgets 2.9 (not really paying enough attention to the numbering)
>
> --
> Eric Kow <http://erickow.com>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>