Hi all, I have downloaded the sources from Darcs and I am trying to isolate the critical components of YHC. Does anyone have resources that explains the overview of the source tree...important folders, main program, etc? Can anyone give a rough overview? Thanks in advance. Below are some of the main folders below the root...in particular I am interested in the src folder. ================================================== Main.hs Sconstruct configure version Makefile config.h.in configure.ac Makefile.in config.h.new.in readme.txt Make=: CMake.hs Configure.hs Docs.hs Profile.hs src Compile.hs Depends.hs Main.hs Useful.hs bootstrap=: packages misc=: Batch.hs Makefile.bpp haddock_prefix.txt DarcsGraph.hs WinYhe.svg hscolour.css src=: SConscript interactive packages tester util compiler98 libraries runtime translator Cheers, -- </Alexis>
Hi Alexis,
I have downloaded the sources from Darcs and I am trying to isolate the critical components of YHC. Does anyone have resources that explains the overview of the source tree...important folders, main program, etc? Can anyone give a rough overview?
If you give us a quick hint at what you are most interested in we can point you in the right direction :)
Make Experimental and incomplete Haskell build system - not currently used
bootstrap Bootstrapping stuff, hand written hi files
misc Left over stuff.
src The good stuff!
interactive = yhci packages = Haskell libraries tester = test framework compiler98 = the compiler libraries = Yhc.Core stuff runtime = yhi translator = javascript stuff Thanks Neil
Hi Neil,
Thanks for the reply. As I'm interested in porting YHC to the Lego
Mindstorms NXT, I am guessing that I would need to be more familiar with the
source...at present I am trying to work through the instructions on porting
the tool on the site, but also would like to know which pieces are the bare
minimum for having a working YHC VM.
The plan is to have YHC layered on top of the NXT firmware with some API
wrappers for using the lego drivers. So for the VM I am trying to figure out
where such an API would fit in with the existing framework and what files
need to be involved...I was planning to write this interface in C originally
but now I see that the source is in Haskell, so I'll have my hands full with
that :) but first I'm just surveying the YHC stuff to see how it fits.
Another option someone mentioned was to have GCC convert code to abstract C
and then run that...does YHC do something similar using STG/abstract C??
Cheers,
On 6/5/07, Neil Mitchell
Hi Alexis,
I have downloaded the sources from Darcs and I am trying to isolate the critical components of YHC. Does anyone have resources that explains the overview of the source tree...important folders, main program, etc? Can anyone give a rough overview?
If you give us a quick hint at what you are most interested in we can point you in the right direction :)
Make Experimental and incomplete Haskell build system - not currently used
bootstrap Bootstrapping stuff, hand written hi files
misc Left over stuff.
src The good stuff!
interactive = yhci packages = Haskell libraries tester = test framework compiler98 = the compiler libraries = Yhc.Core stuff runtime = yhi translator = javascript stuff
Thanks
Neil
-- </Alexis>
Hi Alexis,
The plan is to have YHC layered on top of the NXT firmware with some API wrappers for using the lego drivers. So for the VM I am trying to figure out where such an API would fit in with the existing framework and what files need to be involved...I was planning to write this interface in C originally but now I see that the source is in Haskell, so I'll have my hands full with that :) but first I'm just surveying the YHC stuff to see how it fits.
Yhi is all written in C, and you are unlikely to need to delve into the Haskell side of things. src/runtime/BCKernel should be where you spend most of your time.
Another option someone mentioned was to have GCC convert code to abstract C and then run that...does YHC do something similar using STG/abstract C??
Not really, GHC does, but its hardly abstract C. I'd definitely follow the bytecode route, or you're going to be doing a lot more work. Thanks Neil
participants (2)
-
Alexis Morris -
Neil Mitchell