From: Axel S. <A....@ke...> - 2003-11-16 14:20:08
|
Hi Duncan, the demo of the sourceview widget doesn't work for me: ~/source/testbuild/gtk2hs-0.9.4/demo/sourceview:$ ./sourceview Fail: user error Reason: Pattern match failure in do expression at SourceViewTest.hs:18 The following files are in the local directory: ~/source/testbuild/gtk2hs-0.9.4/demo/sourceview:$ ls Main.hi SourceViewTest.hs haskell.lang Makefile SourceViewTest.o sourceview Any ideas? Axel. |
From: Duncan C. <du...@co...> - 2003-11-16 15:33:41
|
On Sun, 2003-11-16 at 14:19, Axel Simon wrote: > Hi Duncan, > > the demo of the sourceview widget doesn't work for me: > > ~/source/testbuild/gtk2hs-0.9.4/demo/sourceview:$ ./sourceview > > Fail: user error > Reason: Pattern match failure in do expression at SourceViewTest.hs:18 line 16-18: -- create the appropriate language lm <- sourceLanguagesManagerNew Just lang <- sourceLanguagesManagerGetLanguageFromMimeType lm "text/x-haskell" Yes, what's happening is that the current directory is not in the search path for .lang files (so getting the language for that mime type returns Nothing). By default it searches in /usr/share/gtksourceview-1.0/language-specs/ and $HOME/gtksourceview-1.0/language-specs/ The search path can be modified by setting the "lang_files_dirs" property on the SourceLanguagesManager object. I hadn't done that for the demo before because I wasn't up to creating GSLists of strings. Now that the GSList stuff is sorted out, I'll patch the demo shortly. For a temporary fix, just to see the demo working, copy the haskell.lang file to /usr/share/gtksourceview-1.0/language-specs/ or $HOME/gtksourceview-1.0/language-specs/ Duncan |
From: Duncan C. <dun...@wo...> - 2003-11-17 13:16:08
|
On Sun, 2003-11-16 at 15:34, Duncan Coutts wrote: > On Sun, 2003-11-16 at 14:19, Axel Simon wrote: > > the demo of the sourceview widget doesn't work for me: > Yes, what's happening is that the current directory is not in the search > path for .lang files (so getting the language for that mime type returns > Nothing). By default it searches in > /usr/share/gtksourceview-1.0/language-specs/ > and $HOME/gtksourceview-1.0/language-specs/ > > The search path can be modified by setting the "lang_files_dirs" > property on the SourceLanguagesManager object. I hadn't done that for > the demo before because I wasn't up to creating GSLists of strings. Now > that the GSList stuff is sorted out, I'll patch the demo shortly. Actually, it's not so easy. :-( The "lang_files_dirs" parameter is marked G_PARAM_CONSTRUCT_ONLY which means it must (as far as I can tell) be initialised in the call to g_object_newv. After that, the value cannot be changed. I suppose I'd do it like so: sourceLanguagesManagerNewWithLangDirs :: [FilePath] -> IO SourceLanguagesManager sourceLanguagesManagerNewWithLangDirs dirs = makeNewGObject mkSourceLanguagesManager $ do lmtype <- {#call source_languages_manager_get_type#} dirsPtrs <- mapM newUTFString dirs dirsList <- toGSList dirsPtrs newGObject lmtype [("lang_files_dirs", GVpointer dirsList)] {#call g_slist_delete#} dirsList using the as-yet-unbound newGObject :: Int -> [(String, GValue)] -> GObject newGObject typeCode constructorParams = ... {#call g_object_newv#} ... Maybe we could do something more cunning than the above type signature, using classes to hide the type codes and give the exact return type rather than just GObject. As a separate issue, I'm still stuck with wrapping GtkSourceMark. This was the problem due to GtkSourceMark being defined by typedef GtkTextMark GtkSourceMark; I tried the technique where we pretend GtkSourceMark derives from GtkTextMark. Even if we ignore the fact that there is no source_mark_get_type function, c2hs still stumbles because it cannot find GtkSourceMark defined in the .h files. It doesn't consider the typedef. I can't simply pretend that all the functions are dealing with TextMarks because then c2hs sees the GtkSourceMark type parameters in the .h file and generates bindings using Ptr () types everywhere and doesn't emit the withForiegnPtr stuff. A feature request to Manuel perhaps? Duncan |
From: Axel S. <A....@ke...> - 2003-11-17 15:50:24
|
On Mon, Nov 17, 2003 at 01:17:26PM +0000, Duncan Coutts wrote: > On Sun, 2003-11-16 at 15:34, Duncan Coutts wrote: > > On Sun, 2003-11-16 at 14:19, Axel Simon wrote: > > > the demo of the sourceview widget doesn't work for me: > > > Yes, what's happening is that the current directory is not in the search > > path for .lang files (so getting the language for that mime type returns > > Nothing). By default it searches in > > /usr/share/gtksourceview-1.0/language-specs/ > > and $HOME/gtksourceview-1.0/language-specs/ > > > > The search path can be modified by setting the "lang_files_dirs" > > property on the SourceLanguagesManager object. I hadn't done that for > > the demo before because I wasn't up to creating GSLists of strings. Now > > that the GSList stuff is sorted out, I'll patch the demo shortly. > > Actually, it's not so easy. :-( > > The "lang_files_dirs" parameter is marked G_PARAM_CONSTRUCT_ONLY which > means it must (as far as I can tell) be initialised in the call to > g_object_newv. After that, the value cannot be changed. It has also a G_PARAM_READWRITE. Maybe it is possible to write it later. I can imagine that it is possible before you actually construct a sourceview widget with it. Could you try with objectSetProperty from gtk/abstract/Object.chs ? > I suppose I'd do it like so: > > sourceLanguagesManagerNewWithLangDirs :: [FilePath] -> IO SourceLanguagesManager > sourceLanguagesManagerNewWithLangDirs dirs = > makeNewGObject mkSourceLanguagesManager $ do > lmtype <- {#call source_languages_manager_get_type#} > dirsPtrs <- mapM newUTFString dirs > dirsList <- toGSList dirsPtrs > newGObject lmtype [("lang_files_dirs", GVpointer dirsList)] > {#call g_slist_delete#} dirsList Well, if all fails, I guess then we have to take that route. > As a separate issue, I'm still stuck with wrapping GtkSourceMark. This > was the problem due to GtkSourceMark being defined by > typedef GtkTextMark GtkSourceMark; > I tried the technique where we pretend GtkSourceMark derives from > GtkTextMark. Even if we ignore the fact that there is no > source_mark_get_type function, c2hs still stumbles because it cannot > find GtkSourceMark defined in the .h files. It doesn't consider the > typedef. I can't simply pretend that all the functions are dealing with > TextMarks because then c2hs sees the GtkSourceMark type parameters in > the .h file and generates bindings using Ptr () types everywhere and > doesn't emit the withForiegnPtr stuff. > Did you add #include<gtksourceview/gtksourceviewmarker.h> to sourceview.h? I did, and it compiles. There is a gtk_source_marker_get_type in gtksourcemarker.h. I commited the changes. (Together with a bug in hierarchyGen/TypeGen.hs.) Axel. |
From: Duncan C. <dun...@wo...> - 2003-11-17 19:58:23
|
> > The "lang_files_dirs" parameter is marked G_PARAM_CONSTRUCT_ONLY which > > means it must (as far as I can tell) be initialised in the call to > > g_object_newv. After that, the value cannot be changed. > > It has also a G_PARAM_READWRITE. Maybe it is possible to write it later. I > can imagine that it is possible before you actually construct a sourceview > widget with it. Could you try with objectSetProperty from > gtk/abstract/Object.chs ? That's what I tried first, however it doesn't work. Looking at the code, we can see that it shouldn't have been marked G_PARAM_WRITE: void gtk_source_languages_manager_set_specs_dirs (...) { g_return_if_fail (lm->priv->language_specs_directories == NULL); if (dirs == NULL) { //set lm->priv->language_specs_directories //with default entries } else { //return copy of lm->priv->language_specs_directories } } If a G_PARAM_CONSTRUCT_ONLY property is not set during g_object_new, then it gets set with the default value for its data type, NULL in this case. This initialises lm->priv->language_specs_directories with the default entries. Now when we set the property the assertion at the beginning fails as lm->priv->language_specs_directories has already been set. To be honnest, from the rest of the code, I don't see much problem with making the property properly read/write, it would just need to regenerate the list of languages by rescanning the given directories. But for the moment what's what the published version does. :-( > Did you add #include<gtksourceview/gtksourceviewmarker.h> to sourceview.h? > I did, and it compiles. There is a gtk_source_marker_get_type in > gtksourcemarker.h. Oops, got some names wrong SourceMark vs SourceMarker. However, even after fixing that c2hs still emits untyped bindings: for sourceMarkerGetLine :: SourceMarker -> IO Int sourceMarkerGetLine mark = liftM fromIntegral $ {#call unsafe source_marker_get_line#} mark it emits: foreign import ccall unsafe " gtk_source_marker_get_line" gtk_source_marker_get_line :: ((Ptr ()) -> (IO CInt)) That is with {#import Hierarchy#} {#import SourceViewType#} at the top, and SourceMarker inheriting from TextMark. Duncan |
From: Axel S. <A....@ke...> - 2003-11-17 23:55:59
|
On Mon, Nov 17, 2003 at 07:59:23PM +0000, Duncan Coutts wrote: > > widget with it. Could you try with objectSetProperty from > > gtk/abstract/Object.chs ? > [..] > > If a G_PARAM_CONSTRUCT_ONLY property is not set during g_object_new, > then it gets set with the default value for its data type, NULL in this > case. This initialises lm->priv->language_specs_directories with the > default entries. Now when we set the property the assertion at the > beginning fails as lm->priv->language_specs_directories has already been > set. > > To be honnest, from the rest of the code, I don't see much problem with > making the property properly read/write, it would just need to > regenerate the list of languages by rescanning the given directories. > But for the moment what's what the published version does. :-( Yes, we should work around it now. > > Did you add #include<gtksourceview/gtksourceviewmarker.h> to sourceview.h? > > I did, and it compiles. There is a gtk_source_marker_get_type in > > gtksourcemarker.h. > > Oops, got some names wrong SourceMark vs SourceMarker. However, even > after fixing that c2hs still emits untyped bindings: [..] The problem is that c2hs for whatever reason chases all the way to the structure when defining a pointer which is actually only a typedef. That is definitely wrong IMHO and I've fixed that in the gtk2hs c2hs version. I'll submit it as a but to Manuel. This now compiles without problems: > sourceMarkerGetLine :: SourceMarker -> IO Int > sourceMarkerGetLine mark = liftM fromIntegral $ > {#call unsafe source_marker_get_line#} mark It's fixed in the CVS now. I hope I didn't break anything else. Axel. |
From: Duncan C. <dun...@wo...> - 2003-11-19 14:19:48
Attachments:
SourceMarker.chs
sourceview.patch
|
On Mon, 2003-11-17 at 23:55, Axel Simon wrote: > The problem is that c2hs for whatever reason chases all the way to the > structure when defining a pointer which is actually only a typedef. That > is definitely wrong IMHO and I've fixed that in the gtk2hs c2hs version. > I'll submit it as a but to Manuel. > > This now compiles without problems: > > > sourceMarkerGetLine :: SourceMarker -> IO Int > > sourceMarkerGetLine mark = liftM fromIntegral $ > > {#call unsafe source_marker_get_line#} mark > > > It's fixed in the CVS now. I hope I didn't break anything else. Yay! It works now. :-) Attached is the SourceMarker binding that now compiles ok due to the c2hs fix. Also attached is various improvments/fixes to other modules. I've added SourceMarker and SourceStyleScheme interface into the hierarchy.list. More functions in SourceBuffer.chs and SourceLanguage.chs are now bound. Is there a better way to return 32bit unicode chars as ghc's unicode Char type. What I've used at the moment is not very satisfactory (and may not even work across the full value range): ((toEnum . fromEnum) char) Another thing I've noticed is that the build dependencies don't seem to be quite right. I sometimes get: /home/duncan/prgs/build/gtk2hs/c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=600 +RTS -H180m -M350m -RTS -C-I/usr/include/gtksourceview-1.0 -C-I/usr/include/gtk-2.0 -C-I/usr/include/libxml2 -C-I/usr/include/libgnomeprint-2.2 -C-I/usr/lib/gtk-2.0/include -C-I/usr/include/atk-1.0 -C-I/usr/include/pango-1.0 -C-I/usr/X11R6/include -C-I/usr/include/freetype2 -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include -C-I/usr/include/libart-2.0 -i../gtk/glib:../gtk/abstract:../gtk/general:../gtk/multiline:. -o : sourceview.h SourceViewType.chs SourceBuffer.chs SourceLanguage.chs SourceLanguagesManager.chs SourceMarker.chs SourceStyleScheme.chs SourceTag.chs SourceTagTable.chs SourceView.chs c2hs: SourceMarker.chi not found in: ../gtk/glib ../gtk/abstract ../gtk/general ../gtk/multiline . . The problem here is that SourceBuffer.chs {#imports SourceMarker#}, so looks for the .chi file, but the order of the above commandline puts SourceBuffer before SourceMarker. The consequence is that a clean/first time build fails. :-( Duncan |
From: Axel S. <A....@ke...> - 2003-11-19 15:20:58
|
On Wed, Nov 19, 2003 at 02:21:52PM +0000, Duncan Coutts wrote: > On Mon, 2003-11-17 at 23:55, Axel Simon wrote: > > The problem is that c2hs for whatever reason chases all the way to the > > structure when defining a pointer which is actually only a typedef. That > > is definitely wrong IMHO and I've fixed that in the gtk2hs c2hs version. > > I'll submit it as a but to Manuel. > > > > This now compiles without problems: > > > > > sourceMarkerGetLine :: SourceMarker -> IO Int > > > sourceMarkerGetLine mark = liftM fromIntegral $ > > > {#call unsafe source_marker_get_line#} mark > > > > > > It's fixed in the CVS now. I hope I didn't break anything else. > > Yay! It works now. :-) > > Attached is the SourceMarker binding that now compiles ok due to the > c2hs fix. Also attached is various improvments/fixes to other modules. > > I've added SourceMarker and SourceStyleScheme interface into the > hierarchy.list. Could you commit yourself? Just add an entry in the ChangeLog file. > More functions in SourceBuffer.chs and SourceLanguage.chs are now bound. Nice! > Is there a better way to return 32bit unicode chars as ghc's unicode > Char type. What I've used at the moment is not very satisfactory (and > may not even work across the full value range): > > ((toEnum . fromEnum) char) 31-bit Unicode charaters should be fine. In ghc's StgTypes.h it says: typedef StgWord32 StgChar; > > Another thing I've noticed is that the build dependencies don't seem to > be quite right. I sometimes get: [..] > The problem here is that SourceBuffer.chs {#imports SourceMarker#}, so > looks for the .chi file, but the order of the above commandline puts > SourceBuffer before SourceMarker. > > The consequence is that a clean/first time build fails. :-( If SourceBuffer uses any pointers defined in SourceMarker then you need to use {#import SourceMarker#}, otherwise import SourceMarker is enough. It is enought in TextBuffer.chs (although that file does {#import TextIter#}). If a normal import doesn't work then you need to add NEEDCHI = SourceMarker in the Makefile. That will ensure that SourceMarker is always processed first. Thanks, Axel. |
From: Axel S. <A....@ke...> - 2003-11-19 08:33:28
|
Duncan, On Mon, Nov 17, 2003 at 01:17:26PM +0000, Duncan Coutts wrote: > using the as-yet-unbound > newGObject :: Int -> [(String, GValue)] -> GObject > newGObject typeCode constructorParams = > ... {#call g_object_newv#} ... I tried to implement this function which is not a big problem in itself. But putting it into GObject.chs where it belongs is quite challanging which is why I made the release without this function. The problem is a circular dependency of modules between Hierarchy.chs, GValueTypes.chs, GObject.chs and StoreValue.hsc (in treeView/). I could move most code into GObject.chs, even the hsc2hs code, however, I can't join the code with Hierarchy.chs since the latter is automatically generated. I will try to find a way around this without introducing circular modules. It will probably involve moving some functionality that belongs to GObject into Object. I augmented the sourceview demo with a proper error message in case the language file cannot be found. Sorry about that, Axel. |