I want to render a diagram on top of a GUI written with gi-gtk. I tryed to use the defaultRender function from the Diagrams.Backend.Gtk but the compiler is complaining with :
• Couldn't match expected type ‘gtk-0.15.5:Graphics.UI.Gtk.Types.DrawingArea’
with actual type ‘Gtk.DrawingArea’
NB: ‘Gtk.DrawingArea’
is defined in ‘GI.Gtk.Objects.DrawingArea’
in package ‘gi-gtk-3.0.36’
‘gtk-0.15.5:Graphics.UI.Gtk.Types.DrawingArea’
is defined in ‘Graphics.UI.Gtk.Types’ in package ‘gtk-0.15.5’
• In the first argument of ‘defaultRender’, namely ‘canvas’
After verifying the Diagrams.Backend.Gtk, I saw that it is builded with the old Graphics.UI.Gtk.Types from GTk2Hs which seems the cause of this error.
Is there a similar module as Diagrams.Backend.Gtk written with the GI.Gtk package ?
Do you know if in the future the diagrams backend will be build with the GI.Gtk package ?
There is another package diagrams-gi-gtk which probably contains what you are looking for.
I have recently updated it to GTK4, so you might want to use my fork until it gets merged.
Related
A Haskell package (let's call it package A) has stopped compiling for me due to updated dependencies, with an error about an undefined variable. I have access to an old environment of dependencies where the exact same code does still compile, so I can open the module in GHCi and use :info to track down where it originally came from, which leads me to package B.
The trouble is that the now-broken module in A does not directly import the module from B defining this missing identifier; it must have been getting it through another import that re-exports it. But neither A nor B have changed at all changed between the two environments. So that means that a module in some third package C must previously have imported and re-exported my the identifier from B, to then be imported (possibly via further re-exports) by the broken module in A, and C has changed between the two environments to no longer re-export the identifier.
Is there some way I can ask GHC or Cabal in the working environment for the full chain of imports that leads to an identifier being in scope, so that I can identify the package C? Otherwise I don't know how to narrow down the cause of the problem without manually reviewing all of the (transitive) dependencies of A that could plausibly import something from B.
I don't know a way to ask for the whole chain, but you could use -ddump-minimal-imports to ask for the first step in the chain, then iterate.
I have used this tool: https://github.com/etiennestuder/gradle-jooq-plugin
from jOOQ's official website to generate code from my database.
Yet if I set
directory = 'src/main/java'
when I run "gradle build", I get all these compile errors like:
database/information_schema/InformationSchema.java:218: error: no suitable constructor found for SchemaImpl(String,<null>)
super("INFORMATION_SCHEMA", null);
^
constructor SchemaImpl.SchemaImpl(Name) is not applicable
(actual and formal argument lists differ in length)
constructor SchemaImpl.SchemaImpl(String) is not applicable
(actual and formal argument lists differ in length)
Any fix for this?
Note that I wanted to put the generated code into the src folder because I want to use them in my code. I've heard to put them in the target or build folder instead, but I'm not sure how do you access those classes from target or build folder?
Thanks!
I was on 3.7. Now I switch to 3.9, everything turns out to be fine...
I've written a short blog post about this. Starting with jOOQ 3.16 and #12601, there's an additional compilation error in case users use:
An older version of org.jooq:jooq (the runtime library)
A newer version of org.jooq:jooq-codegen (the code generation library)
In general, the runtime library version >= codegen library version. The new compilation error might look like this:
[ERROR] …/DefaultCatalog.java:[53,73] cannot find symbol
[ERROR] symbol: variable VERSION_3_17
[ERROR] location: class org.jooq.Constants
I created some code in the past which use Data.Bytestring.Lazy. Now, when I try to compile it, everithing what I get is a bunch of errors. Example of error:
Couldn't match expected type `BL.ByteString'
with actual type `bytestring-0.10.0.2:Data.ByteString.Lazy.Internal.ByteString'
In the return type of a call of `decompress'
In the second argument of `decrypt', namely `(decompress fc)'
In the second argument of `BL.filter', namely
`(decrypt (extractKey tkey) (decompress fc))'
... And many errors like this ...
My import of bytestring: import Data.ByteString.Lazy as BL.
What to do with this?
EDIT:
THANKS for help. With explicit package version, everything works fine. But, I don't like this solution. When I try to unregister one of the two installed bytestring packages. Many packages will be broken. The newest package version break small amount of packages (no core packages). How to repair packeges which are destroyed by unregistering package?
EDIT:
No, it's not working fine with explicit package version. I wrote edit before I tried it physically. It was mistake. Nothing works.
Yes, I have solved the problem. The evil package was zlib which uses old version of bytestring, but all packages for encryption uses the new version. When I threw away code for compression, my program compiled. Now, I'm looking for some compression algorithms...
I have a windows application including some console and c++ projects.
While building application i am getting below mentioned error:-
error C1084: Cannot read type library file...
Biodentify.Gina.Services.tlb:
Error loading type library/dll
Does anyone know how to solve it?
Is the type library at the right place?
Are your app and the type library both 32bit or 64bit?
Are there any includes in your type library?
If your type library includes another type library, keep in mind that the search path
is the app search path.
One more tricky thing: If a type library has an include, and this included type library is registered, it will be found first.
In module B I have documentation with a link 'A.foo', linking to the foo member of module A. In module A I import module B. Haddock renders this as a link to A.html#t:foo, namely pointing at the type foo (which does not exist) not the function foo, which is at A.html#v:foo.
Why does Haddock link to t: for variables that start with a lower case letter? Is that a bug? For 'A.Foo' I can see that it could be a type or a constructor, so there are namespacing issues. For foo it seems a variable is at least most plausible.
Is there any way to fake a link? I am writing this in code samples, so I need it to be rendered as foo. I tried anchors, but they render as the module name, and for direct hyperlinks you have no control over the displayed text.
I considered a post processor (replacing t:[a-z] with v:), but that requires a custom Setup.hs which causes problems and is quite ugly.
I couldn't find any Haddock command line flags to obtain a more reasonable behavior, such as specifying that foo is a variable.
I can't add an import of A to B without introducing circular imports, which is vile to add purely for documentation.
I am running into this problem in the Shake documentation, where as an example removeFilesAfter does not get the right link.
I can partially answer the the first question (Why?); not sure if it is a bug or desired behaviour.
When haddock resolves references in LexParseRn.rename, it tries to look up the identifier in the environment (via lookupGRE_RdrName). This ought to fail. Next it looks as what the thing could mean (using dataTcOccs from GHC’s RnEnv). The relevant lines are:
dataTcOccs :: RdrName -> [RdrName]
-- Return both the given name and the same name promoted to the TcClsName
-- namespace. This is useful when we aren't sure which we are looking at.
dataTcOccs rdr_name
[...]
| isDataOcc occ || isVarOcc occ
= [rdr_name, rdr_name_tc]
[...]
where
occ = rdrNameOcc rdr_name
rdr_name_tc = setRdrNameSpace rdr_name tcName
so it returns the name first interpreted as whatever it was before (likely a link to a value), and then interpreted as a type constructor. How can a regular name be a type constructor? My guess is that this was added when TypeOperators were reformed in GHC 7.6, which now do share the namespace with value-level operators.
Then haddock matches on the result: If the first one is a type constructor, use that, otherwise use the second. So either it was a type constructor before, then this is used. Or it was not, but then the modified version generated by dataTcOccs is to be used.
It seems to me that haddock should just always use the first option here, and the code is just a mislead copy from how multiple results are used when they can actually be resolved.
This was a Haddock bug #228 and Neil's Haddock bug #253 and the fix has been upstream for few months. You can build GHC HEAD and rebuild your documentation or wait for 7.8 and do it then.