Menu
▾
▴
wxhaskell-devel
|
From: Dave T. <duk...@gm...> - 2011-09-20 19:58:03
|
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, |
|
From: eric.kow <eri...@gm...> - 2011-09-21 14:29:39
|
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> |
|
From: Dave T. <duk...@gm...> - 2011-09-21 18:54:09
Attachments:
use_char_str_instead_of_wchar_str
|
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 |
|
From: David V. <dav...@gm...> - 2011-09-21 14:37:02
|
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 > > |
|
From: Eric Y. K. <eri...@gm...> - 2011-09-21 14:54:49
|
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> |
|
From: David V. <dav...@gm...> - 2011-09-21 15:45:07
|
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> > |
|
From: Eric Y. K. <eri...@gm...> - 2011-09-21 16:06:20
|
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> |
|
From: Dave T. <duk...@gm...> - 2011-09-22 21:29:34
Attachments:
fix_for_prelude_chr_error
|
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. |
Thanks for helping keep SourceForge clean.
X