Re: [Haskell-cafe] Porting GHC to OSX86?

2006-05-10 Thread Scott Weeks
Thanks for your response, I'll follow your saga and hopefully learn a  
bit more about GHC's guts in the process.



On 07/05/2006, at 4:05 AM, Reilly Hayes wrote:



You'll get a better response to this on the glasgow-haskell-users  
list.  I'm cross-posting my reply.


I'm brand new to hacking on GHC, but I've been working on this in  
my pitifully meagre spare time.  The actual expert is Wolfgang  
Thaller, but he doesn't seem to be around the lists lately.  I was  
able to generate hc files on a 386 linux box (actually on a  
Parallels virtual machine on my mac, as my linux boxen all run 64  
bit linuces).I'll share my findings so far:



1) STABLE does not have the appropriate code in the Mangler to deal  
with Darwin/86.  I've been playing with various versions of HEAD.


2) HEAD has gone through a major revision to the directory  
structure.  The documentation and some of the build processes have  
not caught up.  Simon Marlow sent a helpful e-mail to the ghc users  
list a few days ago that you should look at.


3) Building the .hc files mostly requires the appropriate settings  
in mk/build.mk on the Host (linux) machine.  I'll include my  
build.mk below.  There is a target in the top level makefile called  
hc-file-bundle (which needs to be invoked with the parameter  
ProjectNameShort=ghc in HEAD and Project=ghc in STABLE).  This  
target packages up the .hc files, but does not build them.  Some of  
the .hc files in utils (genapply, genprimopcode,  ghc-pkg) don't  
get built.  I just cd to the directories and make them by hand (be  
sure to use the in-place compiler).  A GhcUtilsHcOpts variable in  
the make structure would be nice (in order to pass -keep-hc-files  
to ghc when building these on the host).


4) I have been working with Registerised hc files.  This may have  
been a mistake, as registerised code seems to present some unique  
challenges on Darwin/86.  See the items below for a discussion.


5) If I understand correctly (somebody with better knowledge please  
correct me), there is a register allocation conflict between ghc  
and relocatable code generated by gcc on the 386 (gcc flag -fPIC).   
This limits ghc to producing static binaries.  The gcc in Xcode  
builds relocatable code by default and requires -static to build  
static binaries.


I think this conflict is limited to code that goes through the  
Mangler (registerized code).


6) If I understand correctly, there is code in the RTS that cannot  
be built using the native code generator.  Which suggests that  
we're stuck with static binaries.  There is a ticket to fix this in  
HEAD.


7) Mac OS X really doesn't like static binaries.  In fact, in order  
to link a static binary, you have to go to opendarwin and download  
the Csu package to build crt0.o.  It's not included in any of the  
development tools.  Apple warns that static binaries are likely to  
fail to operate in O/S version changes.


Curently I'm fighting with the Makefiles to figure out how to get  
the -static flag stuffed into all of the invocations of gcc.  Some  
of the invocations in rts components don't seem to obey the normal  
variables used in the makefile structure.  I haven't had time to  
puzzle this out and won't for a few days.



mk/build.mk used to generate hc files:


GhcLibHcOpts = -O -fasm -keep-hc-files
GhcRtsHcOpts = -fasm -keep-hc-files
GhcWithInterpreter = NO
GhcStage1HcOpts = -O
GhcStage2HcOpts = -O -fasm -keep-hc-files
SRC_HC_OPTS += -H32m



-reilly hayes

On May 5, 2006, at 7:34 PM, Scott Weeks wrote:


Hi All,

Does anyone know if there's been any headway on this? If there's not
a port available, where do I go about finding the hc files? Could I
compile on a windows or linux x86 box and use the generated hc files
to bootstrap?

Cheers,
Scott

On 22/03/2006, at 7:09 AM, Deling Ren wrote:


Hi there,

Has anyone made any attempt to port GHC to Mac OS X on x86?
Wolfgang Thaller’s binary package runs over Rosetta but slow (not
surprising). It can not be used to compile a native version either
(I got some errors related to machine registers).

I tried to do a bootstrap but can't find the .HC files mentioned
in the manual. They don't seem to be on the download page of GHC.
Any ideas?

Thanks.

Deling___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Reilly Hayes
[EMAIL PROTECTED]







___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Porting GHC to OSX86?

2006-05-05 Thread Scott Weeks

Hi All,

Does anyone know if there's been any headway on this? If there's not  
a port available, where do I go about finding the hc files? Could I  
compile on a windows or linux x86 box and use the generated hc files  
to bootstrap?


Cheers,
Scott

On 22/03/2006, at 7:09 AM, Deling Ren wrote:


Hi there,

Has anyone made any attempt to port GHC to Mac OS X on x86?  
Wolfgang Thaller’s binary package runs over Rosetta but slow (not  
surprising). It can not be used to compile a native version either  
(I got some errors related to machine registers).


I tried to do a bootstrap but can't find the .HC files mentioned  
in the manual. They don't seem to be on the download page of GHC.  
Any ideas?


Thanks.

Deling___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Ambiguous types for collection keys

2006-04-12 Thread Scott Weeks

Hello everyone,

I've been banging my head against my desk a bit so I figured it's time 
to ask for help :-)


I'm writing an application that persists data to disk. The hard stuff 
is pretty much done (binary serialisation, etc...) The big stumbling 
block is that I want users to be able to define their own schemas. This 
means that the keys for a data store may be Integer, Strings, etc...


I have a BTreeIndex type:

data BTreeIndex a b = Branch { parentBT :: !BlockPtr,
   keysBT   :: ![a],
   kidsBT   :: ![BlockPtr] }
| Leaf   { parentBT :: !BlockPtr,
   valsBT   :: !(LeafMap a b),
   prevBT   :: !PrevLeaf,
   nextBT   :: !NextLeaf }

type IdxPS   = BTreeIndex PackedString BlockPtr
type IdxInt  = BTreeIndex Integer BlockPtr


When a user queries I have to read the input from IO and then somehow 
cast the key/index type without angering the type checker. If I omit 
the following function I get the ominous Ambiguous type variable a... 
error. If I use it I get a complaint that the checker was expecting an 
Integer rather than a PackedString.


coerceIndex f (Schema _ SInt SPtr _) (r,hdl,o,hdr) = f 
(r::IdxInt,hdl,o,hdr)
coerceIndex f (Schema _ SStr SPtr _) (r,hdl,o,hdr) = f 
(r::IdxPS,hdl,o,hdr)


Where f is a curried select function (e.g. selectAll, selectByKey, 
etc...) waiting for the final tuple containing the index and other 
miscellanea that is needed to read the data.


I'm hopelessly lost and I assume that the many brilliant minds on this 
list will chuckle, pat me on the head and tell me what I've been doing 
wrong.


Thanks for your time guys,
Scott
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Ambiguous types for collection keys

2006-04-12 Thread Scott Weeks





Well, if you get an ambiguous type variable error, you probably (I
think) need to add some type annotations. For example:

class Foo a where
  foo :: a
  bar :: a - String

Evaluating bar foo will result in an error, but bar (foo :: Integer)
will work just fine.



The problem is that I get  an incoming value which is a key of some 
sort. There's no way of knowing what type that value is supposed to be 
until I compare it with the schema from the above example. where I _am_ 
adding type annotations.


coerceIndex f (Schema _ SInt SPtr _) (r,hdl,o,hdr) = f 
(r::IdxInt,hdl,o,hdr)
coerceIndex f (Schema _ SStr SPtr _) (r,hdl,o,hdr) = f 
(r::IdxPS,hdl,o,hdr)



When I try to add type annotations I get a complaint from the 
typechecker that says (In the case of the above example) Expected type: 
Integer, Inferred Type: PackedString.


Is the alternative to write different select methods for each key 
type (selectInt, selectPS, ...)? God I hope not, that would be a bit 
scary.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Ambiguous types for collection keys

2006-04-12 Thread Scott Weeks


Or carry an instance in along with a type parameter, using 
existentials or GADT.


Brandon Moore


Do you know of an example that would apply to my situation?

I think I neglected to state part of my problem. I am storing the root 
nodes of btree indexes in a heterogeneous list using Typeable. When 
they come out of the list they need to be unwrapped


I think this will clarify my situation because I've been doing a poor 
job of explaining:


import Data.Dynamic

data Foo a = FVal a
 deriving (Show, Typeable)

type FooStr = Foo String
type FooInt = Foo Integer

main = do
  fooType - getLine
  fooVal  - getLine
  let foo   = toDyn (FVal fooVal)
  fs= [foo]
  (f:_) = fs
  Just dynFoo = fromDynamic f
  dostuff dynFoo



dostuff :: (Show a) = Foo a - IO ()
dostuff (FVal x) = print x


This fails with:

 Ambiguous type variable `a' in the constraints:
  `Typeable a'
	arising from use of `fromDynamic' at 
/Users/weeksie/workspace/haskell/Main.hs:243:20-30

  `Show a'
	arising from use of `dostuff' at 
/Users/weeksie/workspace/haskell/Main.hs:247:2-8

Probable fix: add a type signature that fixes these type variable(s)


However, changing main:

main = do
  fooType - getLine
  fooVal  - getLine
  let foo   = toDyn (FVal fooVal)
  fs= [foo]
  (f:_) = fs
  Just dynFoo = fromDynamic f
  if fooType == str
 then dostuff (dynFoo::FooStr)
 else dostuff (dynFoo::FooInt)


Fails with:

Couldn't match `Integer' against `String'
  Expected type: FooInt
  Inferred type: FooStr
In the expression: dynFoo :: FooInt
In the first argument of `dostuff', namely `(dynFoo :: FooInt)'



I'm probably going about this in the wrong way. I'd love some advice on 
how to either do it better or weave some Type Magic to achieve the same 
effect.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Ambiguous types for collection keys

2006-04-12 Thread Scott Weeks


You are trying to assign two distinct types to dynFoo; that's a no-no. 
 You need to move the usage of the polymorphic function out of the let 
so that the use at each distinct type doesn't get unified.



{-# OPTIONS -fglasgow-exts #-}
import Data.Dynamic

data Foo a = FVal a
 deriving (Show, Typeable)

type FooStr = Foo String
type FooInt = Foo Integer

main = do
  fooType - getLine
  fooVal  - getLine
  let foo   = toDyn (FVal fooVal)
  fs= [foo]
  (f:_) = fs
  if fooType == str
 then dostuff (fromDyn f undefined :: Foo String)
 else dostuff (fromDyn f undefined :: Foo Int)


dostuff :: (Show a) = Foo a - IO ()
dostuff (FVal x) = print x



BTW, this little example always stuffs a string into the FVal, so 
trying to get anything else out will fail.



Thanks for the example it makes a bit of sense now, I really appreciate 
you taking the time to help me on this.


Cheers,
Scott
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] does haskell have plist's ?

2006-02-07 Thread Scott Weeks
I just wanted to say thanks for posting that, I have been struggling 
with a similar problem and I still haven't fully wrapped my head around 
Typeable and fundeps so that PList code you posted helped immensely.


Cheers,
Scott


On 05/02/2006, at 3:57 AM, J. Garrett Morris wrote:


On 2/4/06, raptor [EMAIL PROTECTED] wrote:

does Haskell have a property lists. Like Lisp ?
any pointer to examples ?


Not built in to the language.  It's not hard to get the same
functionality though - I've attached a module that takes a (not
tremendously elegant) approach to the same thing, though.  You'll have
to store PLists explicitly, though, and this requires GHC.

 /g

--
We have lingered in the chambers of the sea 
By sea-girls wreathed with seaweed red and brown
Till human voices wake us, and we drown.
PList.hs___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

2005-11-16 Thread Scott Weeks

The public comment/wiki spam problem is easily solved.

Use JavaScript to generate a value and put it in a hidden form field. 
Check for that value server side, if it's there then allow the post 
otherwise disallow.


Most if not all bots don't have JavaScript engines.


On 16/11/2005, at 10:15 PM, Neil Mitchell wrote:


I don't think restricting editing to registered users is a significant
turn off if registration is simple.


It really really is a turn off. Sometimes when I spot a mistake, and
I'm at a computer where I haven't logged in to hawiki, I don't bother
fixing it. No one wants to have yet another account, to fill in their
personal details yet again.

I appreciate spam is a problem, but turning off unregistered users is
a trade off - less content, less spam, less open to people joining -
its not a free solution.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

2005-11-16 Thread Scott Weeks


Most if not all bots don't have JavaScript engines.


But not all users use JavaScript.



I can certainly understand that some users don't have JavaScript but 
it's the vast minority. The choice is between usability. With captchas 
you can exclude the disabled and people with poor eyesight (as well as 
those who can't be bothered trying to figure out what it says).


Those that have JavaScript turned off are generally technically 
proficient because (in most cases) they've made the choice to turn it 
off. So the choice is still there to post as long as you provide good 
error messages.


So JavaScript is the least intrusive

Captchas are the most

In between would be a form field that asks a very simple question such 
as what's this site about? Hint: it's Haskell


Cheers,
Scott
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] doc/html - wiki - xml

2005-11-15 Thread Scott Weeks
Frankly, the best way to go about writing your doc would be to do it in 
LaTeX/literate haskell. That way you could compile it to 
html/pdf/whatever.


On 15/11/2005, at 2:40 AM, Bulat Ziganshin wrote:


Hello Haskellers,

i'm now write documention about Template Haskell in MS Word. when it
will be written, i will be glad to publish it in Wiki, so anyone can
correct it. and when all be done, it will be great to automatically
convert this wiki text to DocBook XML for inserting in GHC
documentation

can anyone say me about tools/scripts which can be used to do this? or
share your ideas - how can i write scripts to do it?

--
Best regards,
 Bulat  mailto:[EMAIL PROTECTED]



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Information on B-Tree IO implemenations

2005-11-07 Thread Scott Weeks

Thanks Malcolm, that is a great explanation.


In this code, in fact we
managed to keep the lookup function pure, because the Binary interface
allows referentially-transparent I/O (getFAt), which may not be
possible in other serialisation libraries.  This facility however
depends on an invariant that the B-Tree can only be extended - there
is no operation to remove nodes or data.


That's perfect. The insertion functions clear up the IO part of the 
equation immensely and since I will need to be able to delete nodes and 
data it will allow me to implement search/delete myself and cement a 
bit of this in my head.


Cheers, that was a great help.



On 07/11/2005, at 11:12 PM, Malcolm Wallace wrote:


Scott Weeks [EMAIL PROTECTED] writes:


For a project that I'm working on I need to implement a B-Tree or
similar disk based data structure for storing large amounts of data. I
feel like I'm getting it and then I get hung up on disk IO operations
and trying to figure out how they should fit into the mix.


Here is a first-cut specification of a B-Tree:

data BTree k d = BTree Int [(k,[d])] [BTree k d]

where k = key and d = stored data.  Obviously this does not actually
store the B-Tree on file, it just gives a flavour of the intended
structure.

In order to store the data on file, we need to introduce an indirection
corresponding to a file pointer, on each of the child nodes.

data BTree k d = BTree Int [(k,[d])] [FilePtr (BTree k d)]

Then you need a serialisation routine to write any one node of the
tree out and read it back in.  And your tree-traversal routines
(lookup, insert, etc) need to be embedded in the IO monad, so they
can do the necessary file access.

Attached is an implementation of B-Trees (by Colin Runciman), which
uses nhc98's Binary class
http://haskell.org/nhc98/libs/Binary.html
for serialisation.  The type BinHandle corresponds to a file handle,
and Bin corresponds to a file pointer.  In this code, in fact we
managed to keep the lookup function pure, because the Binary interface
allows referentially-transparent I/O (getFAt), which may not be
possible in other serialisation libraries.  This facility however
depends on an invariant that the B-Tree can only be extended - there
is no operation to remove nodes or data.  However the insertion
routine clearly must use I/O to extend the tree.  I hope you can see
the pattern of how this I/O works.

Note also that the B-Tree structure is stored in BPages, separate
from the data values hanging off the tree, which are in DBlocks.

Hope this helps,
Regards,
Malcolm
BTree.hs___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Information on B-Tree IO implemenations

2005-11-06 Thread Scott Weeks

Hello all,

(I'm resending this because I sent the first one without being a member 
of the list and I'm assuming it bounced)


I'm a newbie and while I grasp some of the basics of FP I have yet to 
really understand the guts of Haskell. The type system is starting to 
clear up for me and so are Monads but I have a long way to go.


For a project that I'm working on I need to implement a B-Tree or 
similar disk based data structure for storing large amounts of data. I 
feel like I'm getting it and then I get hung up on disk IO operations 
and trying to figure out how they should fit into the mix.


I'm not necessarily looking for someone to point me at an 
implementation (although I wouldn't mind) but if someone could point me 
in the direction of some material that could shed a light on things I 
would be much obliged.


I've read some Okasaki and found a promising paper called Database 
Manipulation in Haskell 1.3 by Kevin Hammond and Phil Trinder but 
while they talk to the data structures themselves they don't quite get 
around to mentioning how they achieve the IO part of the equation.


Thanks,

Scotty Weeks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe