RE: Talking with the compiler
On Mon, 2004-01-19 at 11:34, Simon Marlow wrote: For the Visual Studio plugin we're going to need to talk to GHCi. We plan to do this by designing an appropriate API for GHCi and calling it directly; you *could* do it by talking over a pipe, but it's going to be a lot of work (and slow). If you want to do this, please talk to us about what API you'd like to see, and we can hopefully implement something that will be generally useful. I wanted something like that for a Haskell IDE I was working on (not much progress on it at the moment, but I may pick it up again). The main things I wanted was enough information to be able to implement jump to definition. Where you select a symbol in your editor and move to where that variable/function/type/class was defined, in the same module or another module. It would also be useful to find out the module and package a symbol comes from so that an IDE could have a good stab at finding some documentation. For that, you'd want an API for wandering through the useful information in .hi files. An API corresponding to hugs/ghci's :info name, :browse modname, :type name would be a good start. You'd want to be able to specify which root module to load up the symbols for, optionally specifing a search path and expect it to also load up the .hi files for any imported modules. This is all stuff that we need for Visual Studio too. VS will typecheck your program as you type, so you'll get errors underlined in the source code. A side effect of this is that it will collect all the information reuqired to implement jump to definition and tell me the type of this identifier in the editor. My plan is to have an API where you can request a :load of a module source (perhaps omitting the code generation steps for speed) and then request information about the module, by source location (GHC now has completely accurate source location information in its abstract datatype; we did this recently in order to support the Visual Studio work). The API will most likely be a derivative of the existing compilation manager interface: see ghc/compiler/compMan/CompManager.lhs. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.2/opengl
we have compiled ghc-6.2 --enable-hopengl from source (with ghc-6.0) on SunOS userv2 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-60. it installs and compiles fine but not for programs that use OpenGL: ghc --make -Wall -fglasgow-exts -package OpenGL ... we get this linker error: Linking ... Undefined first referenced symbol in file glXGetProcAddressARB /usr/local/share/ghc/lib/ghc-6.2/libHSOpenGL_cbits.a(HsOpenGL.o) any ideas? -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Talking with the compiler
On Mon, 2004-01-19 at 11:34, Simon Marlow wrote: For the Visual Studio plugin we're going to need to talk to GHCi. We plan to do this by designing an appropriate API for GHCi and calling it directly; you *could* do it by talking over a pipe, but it's going to be a lot of work (and slow). If you want to do this, please talk to us about what API you'd like to see, and we can hopefully implement something that will be generally useful. I wanted something like that for a Haskell IDE I was working on (not much progress on it at the moment, but I may pick it up again). The main things I wanted was enough information to be able to implement jump to definition. Where you select a symbol in your editor and move to where that variable/function/type/class was defined, in the same module or another module. It would also be useful to find out the module and package a symbol comes from so that an IDE could have a good stab at finding some documentation. For that, you'd want an API for wandering through the useful information in .hi files. An API corresponding to hugs/ghci's :info name, :browse modname, :type name would be a good start. You'd want to be able to specify which root module to load up the symbols for, optionally specifing a search path and expect it to also load up the .hi files for any imported modules. For what I wanted, the ability to evaluate/compile expressions was not necessary, just to browse through symbol information. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.2/opengl
In local.glasgow-haskell-users, you wrote: we have compiled ghc-6.2 --enable-hopengl from source (with ghc-6.0) on SunOS userv2 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-60. Linking ... Undefined first referenced symbol in file glXGetProcAddressARB /usr/local/share/ghc/lib/ghc-6.2/libHSOpenGL_cbits.a(HsOpenGL.o) Can you check your header files? Here it's #ifdef'd inside of GLX_GLXEXT_LEGACY. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Talking with the compiler
Hi, I agree. It would be nice to have also a Iterator interface for the AST, i.e. for jump to next/previous symbol of a special kind. Also information about the caller of a symbol would be nice (I don't know if that is already part of the compiler manager interface). I'm interested in code visualization and refactoring, so this all would be nice to have :-)) BTW: My host system will be Squeak ... greetings Hans Am 20.01.2004 um 11:32 schrieb Simon Marlow: On Mon, 2004-01-19 at 11:34, Simon Marlow wrote: For the Visual Studio plugin we're going to need to talk to GHCi. We plan to do this by designing an appropriate API for GHCi and calling it directly; you *could* do it by talking over a pipe, but it's going to be a lot of work (and slow). If you want to do this, please talk to us about what API you'd like to see, and we can hopefully implement something that will be generally useful. I wanted something like that for a Haskell IDE I was working on (not much progress on it at the moment, but I may pick it up again). The main things I wanted was enough information to be able to implement jump to definition. Where you select a symbol in your editor and move to where that variable/function/type/class was defined, in the same module or another module. It would also be useful to find out the module and package a symbol comes from so that an IDE could have a good stab at finding some documentation. For that, you'd want an API for wandering through the useful information in .hi files. An API corresponding to hugs/ghci's :info name, :browse modname, :type name would be a good start. You'd want to be able to specify which root module to load up the symbols for, optionally specifing a search path and expect it to also load up the .hi files for any imported modules. This is all stuff that we need for Visual Studio too. VS will typecheck your program as you type, so you'll get errors underlined in the source code. A side effect of this is that it will collect all the information reuqired to implement jump to definition and tell me the type of this identifier in the editor. My plan is to have an API where you can request a :load of a module source (perhaps omitting the code generation steps for speed) and then request information about the module, by source location (GHC now has completely accurate source location information in its abstract datatype; we did this recently in order to support the Visual Studio work). The API will most likely be a derivative of the existing compilation manager interface: see ghc/compiler/compMan/CompManager.lhs. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Talking with the compiler
Hello Simon, Am 18.01.2004 um 11:31 schrieb Ketil Malde: [EMAIL PROTECTED] (Hans Nikolaus Beck) writes: in order to build a programming environement, it would be nice to ask the GHC about symbols etc found in a given Haskell program. I suppose a programming environment could talk to GHCi (which provides commands like :type, :info, :browse to explore the currently defined symbols)? I've look shortly at the GHCi documentation. So I think it would be possible to include a GHC engine into a IDE application by redirecting input and output from GHCi to pipes (I rembemer that emacs used something similar for doing it's compile stuff). But that's hardcore UNIX, I've forgot how to do that :-((( sm For the Visual Studio plugin we're going to need to talk to GHCi. We sm plan to do this by designing an appropriate API for GHCi and calling it sm directly; you *could* do it by talking over a pipe, but it's going to be sm a lot of work (and slow). If you want to do this, please talk to us sm about what API you'd like to see, and we can hopefully implement sm something that will be generally useful. we need exactly such a thing for the typebrowser that we are building on top of the theory presented in our ICFP'03 paper. The browser is not going to interact with the compiler, it just needs to gobble up the environment of a given module to get going. Clearly, we would like to spare ourselves the royal pain to implement the module system and all that. At the present stage, the most useful functionality for us would be: 1. Make GHC load a module and then dump the entire symbol table of the current module (all accessible symbols (qualified and unqualified), classes, instances, typings), in some external representation. That external representation might be XML where you just use the names of the types and constructors inside of GHC. (I actually started to hack this up, but it would be nice to have a declared standard for such a representation. Yes, it could be automated using drift, but not all the constructors and fields are interesting outside of GHC, so you want to have intelligent shortcuts. Example: information about which fields in a record type are banged does not matter if you are just interested in typing.) It would be even nicer, if there was a way to have GHC ignore all definitions in the current module and just construct the imported environment. As far as I've seen the datastructures inside GHC allow for that. 2. How about making the annotated syntax tree available in an XML format adapted from the datatypes of the GHC parser? BTW, does Language.Haskell.Parser.parseModule already perform infix resolution? Of course, a library API would be useful, too, but the internal structure of GHC's symbol table is sufficiently complicated that you may not want to expose it. Instead, you'd like some way to look up the information attached to a (qualified) symbol in the current module's scope and get the result in a simple format, i.e., probably not using GHC's internal datatypes. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.2/opengl
Hi there... The following problem was posted to the haskell-users list: We can not build a opengl application with hopengl. We get this error message: Linking ... Undefined first referenced symbol in file glXGetProcAddressARB /usr/local/share/ghc/lib/ghc-6.2/libHSOpenGL_cbits.a(HsOpenGL.o) glXGetProcAddressARB is a function that returns just a pointer to another function. It is used to find out what special gl features your graphiccard or mesa provides. If there isn't that feature you want, this function returns a NULL pointer. I hope I'm right so far. Our system is a SunOS 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-60. I looked around, but I was unable to find any libglX, where this function normally appears. One way to make this all running is to write a foo-bar-glXGetProcAddressARB function that returns everytime the NULL-pointer. But how can I compile this together with the haskell source? Or must I build a *.so library? Or is there a much much easier way to solve this? Cheers Patrick RockMe http://www.yoursort.de Anikas Pharmaziestudium-Seite http://www.pharmazie.net.ms ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Talking with the compiler
Peter wrote: BTW, does Language.Haskell.Parser.parseModule already perform infix resolution? Unless it changed very recently, then no. I have written some code for this very task: http://www.cs.mu.oz.au/~bjpop/code/Infix.hs You give it the infix rules that are in scope and a module and it returns the module with the infix applications resolved. (Of course knowing what rules are in scope is another story, not solved by this piece of code). Perhaps it is of some use to you? Cheers, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
