wxhaskell-devel — wxhaskell developers

Re: [wxhaskell-devel] Is wxHaskell tested on Linux, OS X?

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

I have Ubuntu 12.04 users with hand-compiled wxWidgets 2.9.5 using
current wxHaskell HEAD (2f065e5348343ab95ad3f1465af2619d31bcdf37)

I was using something similar on MacOSX 10.7 (Lion), but now that I've
upgraded to 10.9, I do seem to have some breakage.  Part of it is
confusing though because I also figured I'd try building against
wxWidgets 3.0 (with some tweaks to wxHaskell src to allow for this).

So on 10.7 OK, on 10.9 still having runtime linker error


On 5 December 2013 13:05, Henk-Jan van Tuyl <hj...@ch...> wrote:
>
> L.S.,
>
> Did anyone test the most recent version of wxHaskell on Linux and OS X?
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



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

[wxhaskell-devel] Is wxHaskell tested on Linux, OS X?

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

L.S.,

Did anyone test the most recent version of wxHaskell on Linux and OS X?

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

[wxhaskell-devel] wxHaskell release

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

L.S.,

The wxHaskell version, as currently on GitHub, can be released, as far
as I am concerned. That is, when it is tested and approved on a Linux and
on an OS X system; I tested it on Windows.

For wxWidgets 3.0, some updates are necessary for wxHaskell, before
wxHaskell-for-wxWidgets-3.0 is ready for release, as most wxHaskell sample
programs do not run correctly with wxWidgets 3.0. I propose to use version
number 0.91 for such a release.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

Re: [wxhaskell-devel] New Stable Major wxWidgets 3.0.0 Release

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

On Mon, 18 Nov 2013 16:23:25 +0100, Henk-Jan van Tuyl <hj...@ch...>  
wrote:

> On Sat, 16 Nov 2013 16:12:19 +0100, Eric Kow <eri...@gm...> wrote:
>
>> Great! So hopefully all the work targeting 2.9.x pays off now, and it's
>> just a matter of bumping a few version numbers in the build files?
>>
>> How far do you reckon wxHaskell is from its next release?
>
> There are no version numbers of wxWidgets in wxHaskell

I spoke too soon, the setup of wxc contains a version number (2.9); I will  
try to get things working for both 2.9 and 3.0.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

Re: [wxhaskell-devel] New Stable Major wxWidgets 3.0.0 Release

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

On Sat, 16 Nov 2013 16:12:19 +0100, Eric Kow <eri...@gm...> wrote:

> Great! So hopefully all the work targeting 2.9.x pays off now, and it's  
> just a matter of bumping a few version numbers in the build files?
>
> How far do you reckon wxHaskell is from its next release?

There are no version numbers of wxWidgets in wxHaskell, it is a matter of
indicating where the wxWidgets installation is, against which you want to
build. There may be some differences between wxWidgets 2.9.5 and 3.0.0,
that may require changes in wxHaskell; not all previous changes in
wxWidgets are processed so far.

It is difficult to say, whether or not we want to release the current
wxHaskell; there is a difference of day and night, as far as Windows users
is concerned, as the current Hackage package cannot be installed on a
Windows computer. There are, however, still serious bugs in the GitHub
version.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

Re: [wxhaskell-devel] New Stable Major wxWidgets 3.0.0 Release

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

Great! So hopefully all the work targeting 2.9.x pays off now, and it's just a matter of bumping a few version numbers in the build files?

How far do you reckon wxHaskell is from its next release?

Thanks! :-)

On 14 November 2013 at 20:27:25, Henk-Jan van Tuyl (hj...@ch...) wrote:
>There is a new major release of wxWidgets, see
>http://www.wxwidgets.org/
>


-- 
http://erickow.com

[wxhaskell-devel] New Stable Major wxWidgets 3.0.0 Release

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

L.S.,

There is a new major release of wxWidgets, see
   http://www.wxwidgets.org/

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

Re: [wxhaskell-devel] Exposing the wxc headers as a data structure

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

Thanks for fleshing this out!

Your characterisation of wxc/wxdirect sounds better. Can't claim to be new at this myself, but it's been a while.

In the absence of a response from the devs, I would suggest not waiting for a blessing and going ahead and modifying wxdirect if working from the json for the macro view of the *.h files any easier. You lose nothing from it (well, time, but time that would be spent anyway doing the equivalent pre-processing yourself) and you potentially make life easier for others in the process.  

Only thing I might be nervous about is making wxdirect depend on libraries that don't ship with the Haskellp platform (presumably something like aeson) because I'm not sure what the implications would be for expressing pkg dependencies (when the deps are used for Setup.hs and not the program itself). In the worst case though, you could turn wxdirect into a library and make tool that depends on it.

Would be curious to see how wxOcaml dealt with the same situation, if they just up and parsed our header/macros.

It could also be a good way to become for familiar with wxdirect/wxc.

Thanks!

Eric


On 4 November 2013 at 08:13:26, Martin DeMello (mar...@gm...) wrote:
>
>Hi Eric
>
>I'm new to this too, so I could be wrong, but this is how I understand
>the hierarchy of layers:
>
>* C++ wxWidgets
>* wxc: hand-rolled C wrapper code + header files + macros indicating
>the types that get erased by the C layer
>* wxdirect: "type-aware" header file parser that uses the macros
>within the wxc headers to set up a strongly-typed haskell layer
>corresponding to the original C++ code
>* a few more haskell-specific layers, as you note.
>
>According to the wxHaskell project, the point of doing it this way
>was, in part, to let other languages use the wxc layer as well. Now
>what wxRust etc. would need to do is:
>
>1. Write a low-level binding generator that preprocesses the wxc/*.h
>files, gets rid of the macros etc. and generates direct 1-1 bindings
>to the C functions (fairly straightforward using something like swig
>or the language-specific equivalent; doesn't depend on the specifics
>of the wxc project in any way)
>2. Parse the macro view of wxc/*.h to generate a higher-level
>(strongly typed, object oriented, etc) layer that more closely
>corresponds to the original c++ code, and calls the low-level bindings
>internally.
>
>For instance
>
>TClass(wxPoint) wxListCtrl_GetItemPosition2( TSelf(wxListCtrl) _obj, int item );
>
>would become after preprocessing
>
>void* wxListCtrl_GetItemPosition2(void* _obj, int item);
>
>which in the bindings would generate the corresponding low level function
>
>c_voidptr wxListCtrl_GetItemPosition2(c_voidptr _obj, cint item);
>
>and which would be wrapped by (pseudocode)
>
>class wxListCtrl {
>wxPoint GetItemPosition2(int item) {
>cast(cast self, item);
>}
>}
>
>One problem is that generating this higher level layer from the header
>files is essentially repeating whatever wxdirect does, in every
>language. My idea was that wxdirect be modified to add a -json flag,
>which rather than generating .hs files generates a json view of the
>in-memory data structures it has assembled in the process of parsing
>the files, and that the .json files then be checked in somewhere under
>wxc/. (I'd be willing to contribute the -json flag to wxdirect myself,
>but it'd take me a while; I figured someone already familiar with the
>project could do it in a few hours). That would let other languages
>have an exact idea of the class and method hierarchy, and whether
>method arguments are in, out or in/out, without having to
>independently deduce the information.
>
>In the long run it would be great if wxRust, wxOcaml etc. started
>contributing back to wxc, but to start off I was proposing the simpler
>step of at least building on rather than duplicating the work that
>wxHaskell is doing.
>
>Thanks for the pointer to the wxOcaml reloaded post too; I'd missed
>that. It looks like they're already thinking in terms of starting from
>the original C++ code and generating the C wrappers automatically.
>
>martin
>
>On Sun, Nov 3, 2013 at 9:58 PM, Eric Kow wrote:
>> Hello!
>>
>> First, do you know about the work on wxOcaml?
>> http://www.ocamlpro.com/blog/2013/04/02/wxocaml-reloaded.html
>>
>> Thought it would be good if wxHaskell, wxOcaml, and wxRust made a
>> deliberate point of working together on a single wxC project. (and
>> before anyone suggests autogenerating wxc from wxWidgets via Doxygen,
>> yes, that sounds awesome! but maybe we should still try to pool
>> resources first and then worry about getting wxc done the right way
>> instead of getting stuck salivating over an ideal)
>>
>> As for the proposal itself, sorry I don't really understand it, but
>> I'm not working on wxHaskell much so this is really a question for the
>> not-really-wxHaskell devs like me. Could you remind those of us how
>> things fit together? Do I have this right?
>>
>> * C++ wxWidgets
>> * wxc: Hand-rolled C++ to C wrapper code + header files
>> * wxdirect: utility that parses .h files written using wxc conventions
>> and generates generates Haskell FFI layer code to call the
>> corresponding (wx)C functions
>> * wxcore: autogenerated code via wxdirect (wxc/src/include/*.h =>
>> wxcore/something/.*hs) + some handwritten Haskell
>> * wx: less low-level Haskell code on top of wxcore
>>
>> If so, are you proposing to replace wxc/src/cpp/*.cpp with something
>> like json? That's what your example looks like. I'm a bit confused
>> because I thought it was the effort of parsing of the header files you
>> wanted to avoid duplicating? Would it be possible to autogenerate
>> both the .cpp and the header files from this data structure?
>>
>> Sorry to be dense, and thanks!
>> (I'm guessing your mail only showed up this late because it was caught
>> in the mailman spam filter?)
>>
>>
>> On 9 October 2013 08:06, Martin DeMello wrote:
>>> Hi,
>>>
>>> I'm working on rust bindings to wx, based on the (wonderful!) wxc
>>> layer exposed by wxhaskell. When starting on the wxdirect equivalent,
>>> it struck me that it was wasteful for everyone to be parsing the .h
>>> files - instead, wxc could consist of both the header files and some
>>> sort of serialised data structure (e.g. json):
>>>
>>> C file:
>>>
>>> TClassDefExtend(wxTimerEx,wxTimer)
>>> void wxTimerEx_Connect( TSelf(wxTimerEx) _obj,
>>> TClass(wxClosure) closure );
>>> TClass(wxTimerEx) wxTimerEx_Create( );
>>> TClass(wxClosure) wxTimerEx_GetClosure( TSelf(wxTimerEx) _obj );
>>>
>>> parsed data:
>>>
>>> class: wxTimerEx
>>> parent: wxTimer
>>> methods: [
>>> { c_fn: wxTimerEx_Connect
>>> name: Connect
>>> return_type: void
>>> args: [[wxClosure, closure]]
>>> },
>>> ...
>>> ]
>>>
>>> What do you think? Would this add an unnecessary extra burden? I
>>> figure the data structure is in memory at some point anyway, so
>>> dumping it to a file shouldn't be too much of a problem.
>>>
>>> martin
>>>
>>> ------------------------------------------------------------------------------
>>> Android is increasing in popularity, but the open development platform that
>>> developers love is also attractive to malware creators. Download this white
>>> paper to learn more about secure code signing practices that can help keep
>>> Android apps secure.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> wxhaskell-devel mailing list
>>> wxh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>>
>>
>>
>> --
>> Eric Kow  
>

-- 
http://erickow.com

Re: [wxhaskell-devel] Exposing the wxc headers as a data structure

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

Hello!

First, do you know about the work on wxOcaml?
http://www.ocamlpro.com/blog/2013/04/02/wxocaml-reloaded.html

Thought it would be good if wxHaskell, wxOcaml, and wxRust made a
deliberate point of working together on a single wxC project. (and
before anyone suggests autogenerating wxc from wxWidgets via Doxygen,
yes, that sounds awesome! but maybe we should still try to pool
resources first and then worry about getting wxc done the right way
instead of getting stuck salivating over an ideal)

As for the proposal itself, sorry I don't really understand it, but
I'm not working on wxHaskell much so this is really a question for the
not-really-wxHaskell devs like me.  Could you remind those of us how
things fit together?  Do I have this right?

* C++ wxWidgets
* wxc: Hand-rolled C++ to C wrapper code + header files
* wxdirect: utility that parses .h files written using wxc conventions
and generates generates Haskell FFI layer code to call the
corresponding (wx)C functions
* wxcore: autogenerated code via wxdirect (wxc/src/include/*.h =>
wxcore/something/.*hs) + some handwritten Haskell
* wx: less low-level Haskell code on top of wxcore

If so, are you proposing to replace wxc/src/cpp/*.cpp with something
like json?  That's what your example looks like.  I'm a bit confused
because I thought it was the effort of parsing of the header files you
wanted to avoid duplicating?  Would it be possible to autogenerate
both the .cpp and the header files from this data structure?

Sorry to be dense, and thanks!
(I'm guessing your mail only showed up this late because it was caught
in the mailman spam filter?)


On 9 October 2013 08:06, Martin DeMello <mar...@gm...> wrote:
> Hi,
>
> I'm working on rust bindings to wx, based on the (wonderful!) wxc
> layer exposed by wxhaskell. When starting on the wxdirect equivalent,
> it struck me that it was wasteful for everyone to be parsing the .h
> files - instead, wxc could consist of both the header files and some
> sort of serialised data structure (e.g. json):
>
> C file:
>
> TClassDefExtend(wxTimerEx,wxTimer)
> void               wxTimerEx_Connect( TSelf(wxTimerEx) _obj,
> TClass(wxClosure) closure );
> TClass(wxTimerEx)  wxTimerEx_Create(  );
> TClass(wxClosure)  wxTimerEx_GetClosure( TSelf(wxTimerEx) _obj );
>
> parsed data:
>
> class: wxTimerEx
> parent: wxTimer
> methods: [
>   { c_fn: wxTimerEx_Connect
>     name: Connect
>     return_type: void
>     args: [[wxClosure, closure]]
>   },
>   ...
> ]
>
> What do you think? Would this add an unnecessary extra burden? I
> figure the data structure is in memory at some point anyway, so
> dumping it to a file shouldn't be too much of a problem.
>
> martin
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



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

Re: [wxhaskell-devel] wxHaskell vs GHCi

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

Thanks! I've taken the liberty of filing this at
https://sourceforge.net/p/wxhaskell/bugs/84/

Conal, am just CC'ing you because you've been suffering most from this
GHCi bug, which I think sounds important.  Just letting you know that
we now have a BTS ticket for it, and some technical info on said
ticket.

Sorry for not being more helpful; just hoping this tiny bit of admin
dot-connecting can help move things forward.

As I understand it, the new new wxHaskell crew have been very active —
thanks guys! — but are now focused on getting a new release out from
all their hard work lately.  So this GHCi-related stuff would have to
be after said release

On 8 October 2013 16:16, Jeremy O'Donoghue <jer...@gm...> wrote:
>
> When I last looked at the problem, the issue was that wxWidgets libraries
> use static constructors and destructors in some places.
>
> Problem with static constructors is that they typically run before main() -
> or its equivalent - is called. This means that once you quit an application,
> there is no way to restart without relaunching executable.
>
> Similarly, static destructors only run after app has called exit().
>
> There were a couple of approaches I considered:
> * Implement a wrapper which forces dynamic load and unload of the wxWidgets
> libraries from inside wxc. This would work because when reloading the
> libraries (as you would when restarting app at GHCi), the static
> constructors run (e.g. in Windows they usually run just before DllMain() is
> called). This is easy, but very tedious to do in practice, and would only
> really make sense if the wxWidgets bindings are auto-generated.
>
> * Fake application exit when running in GHCi so that when app starts again
> the same event loop is used, and the static destructors are never called.
> This would be a very neat solution, but state management is very tricky.
>
> Regards
> Jeremy
>
> On 7 October 2013 06:53, Eric Kow <eri...@gm...> wrote:
>>
>> I couldn't find a relevant bug on the wxHaskell tracker (all were closed)
>> Perhaps it'd be worthwhile creating a new ticket for the problems
>> Conal was facing? (they are very old problems, if I remember
>> correctly).
>>
>> Do we even know what the issue is about?
>>
>> On 6 October 2013 20:54, Henk-Jan van Tuyl <hj...@ch...> wrote:
>> > On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow <eri...@gm...> wrote:
>> >
>> >> Just thought I might call your attention to this thread:
>> >>
>> >> http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
>> >>
>> >> GHCi support seems like something that might be worth bubbling up the
>> >> agenda?
>> >
>> >
>> > Shouldn't GHCi support be all right with the next GHC release? Did
>> > someone
>> > try a nightly build of GHC to test this? There are no nightly builds for
>> > Windows, and I can't get GHC compiled, so I cannot test this.
>> >
>> > Regards,
>> > Henk-Jan van Tuyl
>> >
>> >
>> > --
>> > Folding@home
>> > What if you could share your unused computer power to help find a cure?
>> > In
>> > just 5 minutes you can join the world's biggest networked computer and
>> > get
>> > us closer sooner. Watch the video.
>> > http://folding.stanford.edu/
>> >
>> >
>> > http://Van.Tuyl.eu/
>> > http://members.chello.nl/hjgtuyl/tourdemonad.html
>> > Haskell programming
>> > --
>>
>>
>>
>> --
>> Eric Kow <http://erickow.com>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>



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

Re: [wxhaskell-devel] Architecture (32 vs. 64 bit) of the dynamic libraries

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

On Sat, 05 Oct 2013 14:02:11 +0200, Henk-Jan van Tuyl <hj...@ch...>  
wrote:

>
> L.S.,
>
> I am trying to implement a check if the architecture (32 vs. 64 bit) of
> the dynamic libraries of wxWidgets matches the architecture that  
> wxHaskell is being built with.

I have implemented this and pushed it to the repository. When the wxc  
setup is run on Windows, Linux or OS X, the message "The bitness is  
correct" should be given. If the message is "The bitness is not checked",  
the setup could probably not find a proper dynamic library; this should be  
considered to be a bug. (Setup searches for a dynamic library in the  
wxWidgets directory, not in the search path.)

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

[wxhaskell-devel] Exposing the wxc headers as a data structure

[Martin D. <mar...@gm...>]

Hi,

I'm working on rust bindings to wx, based on the (wonderful!) wxc
layer exposed by wxhaskell. When starting on the wxdirect equivalent,
it struck me that it was wasteful for everyone to be parsing the .h
files - instead, wxc could consist of both the header files and some
sort of serialised data structure (e.g. json):

C file:

TClassDefExtend(wxTimerEx,wxTimer)
void               wxTimerEx_Connect( TSelf(wxTimerEx) _obj,
TClass(wxClosure) closure );
TClass(wxTimerEx)  wxTimerEx_Create(  );
TClass(wxClosure)  wxTimerEx_GetClosure( TSelf(wxTimerEx) _obj );

parsed data:

class: wxTimerEx
parent: wxTimer
methods: [
  { c_fn: wxTimerEx_Connect
    name: Connect
    return_type: void
    args: [[wxClosure, closure]]
  },
  ...
]

What do you think? Would this add an unnecessary extra burden? I
figure the data structure is in memory at some point anyway, so
dumping it to a file shouldn't be too much of a problem.

martin

Re: [wxhaskell-devel] wxHaskell vs GHCi

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

When I last looked at the problem, the issue was that wxWidgets libraries
use static constructors and destructors in some places.

Problem with static constructors is that they typically run before main() -
or its equivalent - is called. This means that once you quit an
application, there is no way to restart without relaunching executable.

Similarly, static destructors only run after app has called exit().

There were a couple of approaches I considered:
* Implement a wrapper which forces dynamic load and unload of the wxWidgets
libraries from inside wxc. This would work because when reloading the
libraries (as you would when restarting app at GHCi), the static
constructors run (e.g. in Windows they usually run just before DllMain() is
called). This is easy, but very tedious to do in practice, and would only
really make sense if the wxWidgets bindings are auto-generated.

* Fake application exit when running in GHCi so that when app starts again
the same event loop is used, and the static destructors are never called.
This would be a very neat solution, but state management is very tricky.

Regards
Jeremy

On 7 October 2013 06:53, Eric Kow <eri...@gm...> wrote:

> I couldn't find a relevant bug on the wxHaskell tracker (all were closed)
> Perhaps it'd be worthwhile creating a new ticket for the problems
> Conal was facing? (they are very old problems, if I remember
> correctly).
>
> Do we even know what the issue is about?
>
> On 6 October 2013 20:54, Henk-Jan van Tuyl <hj...@ch...> wrote:
> > On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow <eri...@gm...> wrote:
> >
> >> Just thought I might call your attention to this thread:
> >>
> http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
> >>
> >> GHCi support seems like something that might be worth bubbling up the
> >> agenda?
> >
> >
> > Shouldn't GHCi support be all right with the next GHC release? Did
> someone
> > try a nightly build of GHC to test this? There are no nightly builds for
> > Windows, and I can't get GHC compiled, so I cannot test this.
> >
> > Regards,
> > Henk-Jan van Tuyl
> >
> >
> > --
> > Folding@home
> > What if you could share your unused computer power to help find a cure?
> In
> > just 5 minutes you can join the world's biggest networked computer and
> get
> > us closer sooner. Watch the video.
> > http://folding.stanford.edu/
> >
> >
> > http://Van.Tuyl.eu/
> > http://members.chello.nl/hjgtuyl/tourdemonad.html
> > Haskell programming
> > --
>
>
>
> --
> Eric Kow <http://erickow.com>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

Re: [wxhaskell-devel] Architecture (32 vs. 64 bit) of the dynamic libraries

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

I don't have wx 2.9.5 around (by default Ubuntu 13.04 has 2.8)
I hope it's still useful:

Ubuntu 13.04 64 bits:
file /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0.8.0
/usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0.8.0: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=0x0bafe1a3326e52df37488362db5bac009049766f, stripped

Regards,

Re: [wxhaskell-devel] wxHaskell vs GHCi

[Atze D. <at...@uu...>]

I think now is then a good moment to wrap things up for a release, that is, make a branch for it, check whether everything still works on all available platforms, and at least get a (relatively) stable version on hackage. After that we can try to reconstruct the GHCi problem and/or see whether GHC 7.8 (automatically) solves this problem.

Atze

On  7 Oct, 2013, at 07:53 , Eric Kow <eri...@gm...> wrote:

> I couldn't find a relevant bug on the wxHaskell tracker (all were closed)
> Perhaps it'd be worthwhile creating a new ticket for the problems
> Conal was facing? (they are very old problems, if I remember
> correctly).
> 
> Do we even know what the issue is about?
> 
> On 6 October 2013 20:54, Henk-Jan van Tuyl <hj...@ch...> wrote:
>> On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow <eri...@gm...> wrote:
>> 
>>> Just thought I might call your attention to this thread:
>>> http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
>>> 
>>> GHCi support seems like something that might be worth bubbling up the
>>> agenda?
>> 
>> 
>> Shouldn't GHCi support be all right with the next GHC release? Did someone
>> try a nightly build of GHC to test this? There are no nightly builds for
>> Windows, and I can't get GHC compiled, so I cannot test this.
>> 
>> Regards,
>> Henk-Jan van Tuyl
>> 
>> 
>> --
>> Folding@home
>> What if you could share your unused computer power to help find a cure? In
>> just 5 minutes you can join the world's biggest networked computer and get
>> us closer sooner. Watch the video.
>> http://folding.stanford.edu/
>> 
>> 
>> http://Van.Tuyl.eu/
>> http://members.chello.nl/hjgtuyl/tourdemonad.html
>> Haskell programming
>> --
> 
> 
> 
> -- 
> Eric Kow <http://erickow.com>
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


                - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: at...@uu... ............... /   |___\

Re: [wxhaskell-devel] wxHaskell vs GHCi

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

I couldn't find a relevant bug on the wxHaskell tracker (all were closed)
Perhaps it'd be worthwhile creating a new ticket for the problems
Conal was facing? (they are very old problems, if I remember
correctly).

Do we even know what the issue is about?

On 6 October 2013 20:54, Henk-Jan van Tuyl <hj...@ch...> wrote:
> On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow <eri...@gm...> wrote:
>
>> Just thought I might call your attention to this thread:
>> http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
>>
>> GHCi support seems like something that might be worth bubbling up the
>> agenda?
>
>
> Shouldn't GHCi support be all right with the next GHC release? Did someone
> try a nightly build of GHC to test this? There are no nightly builds for
> Windows, and I can't get GHC compiled, so I cannot test this.
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --



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

Re: [wxhaskell-devel] wxHaskell vs GHCi

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

On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow <eri...@gm...> wrote:

> Just thought I might call your attention to this thread:
> http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
>
> GHCi support seems like something that might be worth bubbling up the  
> agenda?

Shouldn't GHCi support be all right with the next GHC release? Did someone  
try a nightly build of GHC to test this? There are no nightly builds for  
Windows, and I can't get GHC compiled, so I cannot test this.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

[wxhaskell-devel] wxHaskell vs GHCi

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

Hi wxHaskell devs,

Just thought I might call your attention to this thread:
http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html

GHCi support seems like something that might be worth bubbling up the agenda?

Cheers,

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

Re: [wxhaskell-devel] Architecture (32 vs. 64 bit) of the dynamic libraries

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

64-bit OS X

/usr/local/lib$ file libwx_baseu-2.9.dylib
libwx_baseu-2.9.dylib: Mach-O 64-bit dynamically linked shared library x86_64

On 5 October 2013 13:02, Henk-Jan van Tuyl <hj...@ch...> wrote:
>
> L.S.,
>
> I am trying to implement a check if the architecture (32 vs. 64 bit) of
> the dynamic libraries of wxWidgets matches the architecture that wxHaskell
> is being built with. See Feature Request #8 [0]. Therefore, I need to see
> the output of the file command for one of those libraries.
>
> So far, I have on this one:
>    C:\wxWidgets-2.9.5\lib\gcc_dll>file wxbase295u_gcc_custom.dll
>    wxbase295u_gcc_custom.dll: PE executable for MS Windows (DLL) (console)
> Intel 80386 32-bit
>
> Could someone provide me with the results from Mac OS X and Linux
> (preferably for both 32 and 64 bit)?
>
> Regards,
> Henk-Jan van Tuyl
>
>
> [0] http://sourceforge.net/p/wxhaskell/feature-requests/8/
>
>
> --
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



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

[wxhaskell-devel] Architecture (32 vs. 64 bit) of the dynamic libraries

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

L.S.,

I am trying to implement a check if the architecture (32 vs. 64 bit) of  
the dynamic libraries of wxWidgets matches the architecture that wxHaskell  
is being built with. See Feature Request #8 [0]. Therefore, I need to see  
the output of the file command for one of those libraries.

So far, I have on this one:
   C:\wxWidgets-2.9.5\lib\gcc_dll>file wxbase295u_gcc_custom.dll
   wxbase295u_gcc_custom.dll: PE executable for MS Windows (DLL) (console)  
Intel 80386 32-bit

Could someone provide me with the results from Mac OS X and Linux  
(preferably for both 32 and 64 bit)?

Regards,
Henk-Jan van Tuyl


[0] http://sourceforge.net/p/wxhaskell/feature-requests/8/


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

[wxhaskell-devel] Administration of the wxHaskell tickets

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

L.S.,

Is there anyone with administrator rights for the wxHaskell tickets on
SourceForge still reading this mailing list? Several open bug tickets can
be closed now.

I am willing to take on administration of the wxHaskell tickets myself.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

Re: [wxhaskell-devel] More packages for the wxHaskell repository, and maintenance of these packages

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

Just a quick note that the xtc package (which Gebop etc may depend on)
is on hackage.

http://hackage.haskell.org/package/xtc

Looks like Alan Zimmerman took it over (for which thanks)
http://github.com/alanz/xtc

BTW, very heartening to see all the wxHaskell activity lately.
Hopefully one day it won't be so sacrifice-a-chicken-ish to install

On 21 September 2013 08:33, Atze Dijkstra <at...@uu...> wrote:
> Hi Henk-Jan,
>
> sure, go ahead, is fine with me!
>
> Atze
>
> On  20 Sep, 2013, at 22:59 , Henk-Jan van Tuyl <hj...@ch...> wrote:
>
>>
>> L.S.,
>>
>> Some time ago, I have put the packages wxAsteroids and GeBoP on Hackage,
>> to promote wxHaskell. I would like to create GitHub repositories for
>> these, next to the official wxHaskell repository, at
>> https://github.com/wxHaskell/ and specify, as maintainer, the wxHaskell
>> developer mailing list. If this is OK with you, I will do this a week from
>> now.
>>
>> Regards,
>> Henk-Jan van Tuyl
>>
>>
>> --
>> Folding@home
>> What if you could share your unused computer power to help find a cure? In
>> just 5 minutes you can join the world's biggest networked computer and get
>> us closer sooner. Watch the video.
>> http://folding.stanford.edu/
>>
>>
>> http://Van.Tuyl.eu/
>> http://members.chello.nl/hjgtuyl/tourdemonad.html
>> Haskell programming
>> --
>>
>> ------------------------------------------------------------------------------
>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>
>                 - Atze -
>
> Atze Dijkstra, Department of Information and Computing Sciences. /|\
> Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
> Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
> Fax : +31-30-2513971 .... | Email: at...@uu... ............... /   |___\
>
>
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



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

Re: [wxhaskell-devel] More packages for the wxHaskell repository, and maintenance of these packages

[Atze D. <at...@uu...>]

Hi Henk-Jan,

sure, go ahead, is fine with me!

Atze

On  20 Sep, 2013, at 22:59 , Henk-Jan van Tuyl <hj...@ch...> wrote:

> 
> L.S.,
> 
> Some time ago, I have put the packages wxAsteroids and GeBoP on Hackage,  
> to promote wxHaskell. I would like to create GitHub repositories for  
> these, next to the official wxHaskell repository, at  
> https://github.com/wxHaskell/ and specify, as maintainer, the wxHaskell  
> developer mailing list. If this is OK with you, I will do this a week from  
> now.
> 
> Regards,
> Henk-Jan van Tuyl
> 
> 
> -- 
> Folding@home
> What if you could share your unused computer power to help find a cure? In  
> just 5 minutes you can join the world's biggest networked computer and get  
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
> 
> 
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
> 
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


                - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: at...@uu... ............... /   |___\

[wxhaskell-devel] More packages for the wxHaskell repository, and maintenance of these packages

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

L.S.,

Some time ago, I have put the packages wxAsteroids and GeBoP on Hackage,  
to promote wxHaskell. I would like to create GitHub repositories for  
these, next to the official wxHaskell repository, at  
https://github.com/wxHaskell/ and specify, as maintainer, the wxHaskell  
developer mailing list. If this is OK with you, I will do this a week from  
now.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

[wxhaskell-devel] Bug tickets

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

L.S.,

I have entered several tickets[0] for bugs I have found while running  
samples from the repository; they are the tickets #65 and up. More tickets  
are coming up; the older tickets are mostly solved.

Regards,
Henk-Jan van Tuyl


[0] http://sourceforge.net/p/wxhaskell/bugs/


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--