RE: (Stupid?) newbie question
Hi, not a stupid question, just a stupid bug in 4.03 ;-) This has been fixed in the patch available from the ghc-win32 web page, http://www.dcs.gla.ac.uk/~sof/ghc-win32.html http://www.dcs.gla.ac.uk/~sof/ghc-win32.html hth --sigbjorn -Original Message- From: felix [mailto:[EMAIL PROTECTED]] Sent: Monday, August 16, 1999 00:45 To: glasgow-haskell-users Subject: (Stupid?) newbie question Hi, folks! I have recently downloaded ghc-4.03 (under win32/cygwin) and everything seems to work great, but somehow the following code snippet does not work as intended: import System main = do argv - getArg print argv This does print "[]" - no arguments! Since the same thing fails in Hugs too, I must have made some mistake. please enlighted me. thanks, felix
RE: CCallable Integers
I think you're asking whether POSIX types should be given a type/synonym on the Haskell side. The Posix library does define some of them, but not all - e.g., size_t isn't. I'm sure patches which extended that library so as to have these would be welcomed by the GHC developers. --sigbjorn George Russell [EMAIL PROTECTED] writes: For historical reasons (I suppose), the text in the Users Guide section 5.4 on calling foreign functions from C seems to assume that you only need C integers (represented by Int). This means it's not clear what to do if, for example, you need size_t. At the moment I suppose most people are still using computers which are basically 32 bit throughout, so at the moment this is something of a non-issue, but in the next few years I expect this to change, and I think the way GHC is tied to a particular correspondence C types - Haskell types is dangerous. So what I suggest is that we have a new structure which contains type synonyms corresponding to the C numeric types (for example CInt, CInt#, CSizeT, CSizeT#, and so on). Also the manual should be changed to encourage people writing new code to use CInt rather that Int as the type name for when they want to call a C function expecting an Int.
RE: redirecting *.hi
Simon Marlow [EMAIL PROTECTED] writes: Sergey: One small correction: The sed script should be: sed -e 's/.*\/\([^\/][^\/]*\)\.hs/$(E)\/\1.o, $(E)\/\1.hi/' Of course: :g/.*\/\([^\/][^\/]*\)\.hs/s//$(E)\/\1.o, $(E)\/\1.hi/ in vi should also work. -odir blah is supposed to work, I think. Not for the gen'ed interface file. If you're using GNU make I'd simply add SRC_HC_OPTS += -ohi $(E)/$*.hi and avoid having to supply them on a case-by-case basis. --sigbjorn
RE: Please could the Concurrency library have a yield action!
George Russell [EMAIL PROTECTED] writes: "Sigbjorn Finne (Intl Vendor)" wrote: Is it worth adding something like `yield' to the Concurrent API? I'm unconvinced, but don't feel strongly about it. If there are others that also think that it should be supported, let me know, and I'll change my mind :-) Here are two reasons: (1) Pre-emptive scheduling is hard to implement (is Hugs really going to support it and still be as portable as it is now??). Presumably this is why Java is not guaranteed to have it. That's the plan - it's usually not that hard to find enough OS support to make the implementation of this possible. (2) Even when you have pre-emptive scheduling, yield() could still provide a hint to the scheduler that this might be a good time to do something else. The scheduler will pretty soon get around to context switching anyway, but ok. There's no persuasive reasons for not supporting it, so we'll add it. --sigbjorn
RE: Q: Threads in GHC's RTS
Sven Panne [EMAIL PROTECTED] writes: [...] Aaaah! *lights going on* But then I suggest that foreign export dynamic should be changed to return a stable pointer instead of an Addr. This shouldn't break too much code, because both are CCallable. I don't see the need, since (deep breath) freeHaskellFunctionPtr() drops the stable pointer for you when passed the Addr that f.e.d. returns. That RTS entry point doesn't have a Haskell wrapper at the moment, so you'll have to 'foreign import' to use it (or _ccall_ it, as we did in the olden days ;) --sigbjorn
RE: Xlib IDL for H/Direct?
Sven Panne [mailto:[EMAIL PROTECTED]] writes:
"Sigbjorn Finne (Intl Vendor)" wrote:
Sven Panne wrote:
What's wrong with using Green Card? Its %enum generates
the desired mappings automatically and consistently. AFAIK,
this type safety is something even IDL compilers don't do
for you.
Use whatever works best for you, but I'm not sure I agree with this
statement re: enums. Care to expand? :)
OK, my mail was a little bit terse, so I'll try again with a hopefully
self-explaining example. First in IDL:
-- Foo.idl --
module Foo {
const int EXIT_FAILURE = 1;
const int EXIT_SUCCESS = 0;
typedef int status_t;
void exit ([in]status_t status);
const int SEEK_SET = 0;
const int SEEK_CUR = 1;
const int SEEK_END = 2;
typedef int whence_t;
typedef unsigned long off_t;
typedef int fd_t;
off_t lseek([in]fd_t fd, [in]off_t offset, [in]whence_t whence);
}
-
And here in Green Card:
-- Bar.gc ---
module Bar where
import StdDIS
import Word
%enum Status Int [ EXIT_FAILURE, EXIT_SUCCESS ]
%fun exit :: Status - IO ()
%enum Whence Int [ SEEK_SET, SEEK_CUR, SEEK_END ]
newtype Offset = Offset Word32;
%dis offset x = Offset (word32 x)
newtype Fd = Fd Int;
%dis fd x = Fd (int x)
%fun lseek :: Fd - Offset - Whence - IO Offset
-
You could use 'const's for this, but I'd suggest using an
'enum' decl in IDL instead. IDL 'enum' declarations are just
like in C, but HDirect extends 'em a little by supporting
the custom 'deriving()' attribute. For example,
typedef [deriving("Eq")]
enum { EXIT_FAILURE = 0, EXIT_SUCCESS } Status;
gives
data Status = EXIT_FAILURE | EXIT_SUCCESS
instance Eq Status where {...}
instance Enum Status where {...}
which should be equal in power to %enum. (HDirect doesn't
currently allow you to map enums to newtypes of Int (say),
but it could. No big deal).
--sigbjorn
Mutable array ops (was: file operations)
Martin Stein [EMAIL PROTECTED] writes:
..
Yes, I tried to use them but missed some functions to handle
ByteArrays, particularly
1. How can I get a ByteArray? (freezing a MutableByteArray
seems to be a little strange)
Strange as it might be, but that's the way :)If you want to
hide the use of MutableByteArrays, you can without too much
effort:
-- untested code.
doubleByteArray :: [Double] - ByteArray Int
doubleByteArray dbls = runST $ do
marr - newDoubleArray (0,len)
zipWithM_ (writeDoubleArray marr) [0..] dlbs
unsafeFreezeByteArray marr
where
len = max 0 (length dbls - 1)
2. How can I thaw a ByteArray to get a MutableByteArray?
By manually copying over the bytes - here's the version that I'll
probably add to the MutableArray interface:
\begin{code}
thawByteArray :: Ix ix = ByteArray ix - ST s (MutableByteArray s ix)
thawByteArray (ByteArray ixs barr#) =
{-
The implementation is made more complex by the
fact that the indexes are in units of whatever
base types that's stored in the byte array.
-}
case (sizeofByteArray# barr#) of
i# - do
marr - newCharArray (0,I# i#)
mapM_ (\ idx@(I# idx#) -
writeCharArray marr idx (C# (indexCharArray# barr# idx#)))
[0..]
let (MutableByteArray _ arr#) = marr
return (MutableByteArray ixs arr#)
\end{code}
The unsafe version of this and thawArray should be supported in the
next release too.
--Sigbjorn
RE: `sort'
Have a look at the Util module in '-syslib misc', it provides a variety of sorting algorithms, including said merge sort. If you want others, check out Ralf Hinze's pages at http://www.informatik.uni-bonn.de/~ralf/ --Sigbjorn [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] writes: Carl R. Witty [EMAIL PROTECTED] writes The merge sorting costs O( n*log(n) ), so it is good in any case. Why not implement it? [...] Sergey gave a suggestion (backed by numbers) for a better algorithm. I would say (and I think Sergey would too) that the standard library should provide an O(n log(n)) sorting algorithm, rather than an algorithm which is O(n log(n)) for some applications and O(n^2) for others (even if the first algorithm is a constant factor of two or three slower than the best case of the second). Sometimes applications do need to sort lists which are nearly sorted, or which may be already sorted... Indeed, i voice for the merge sort - exactly for the reasons you give - adding that the merge sort fits well functional programming, expresses in small and clear program. But i cannot justify the whole solution rigorousely, neither would like to get into long discussion on this not so vital subject. My protest expresses simply in the form of import Listhiding (sort ) import Prelude hiding (minimum,maximum,sum,product) import DPrelude (sort,minimum,maximum,sum,product ...) QuickSort - it is desirable to be provided too (in the List standard library). Only - if it is really true that, like people say, its *average* expense is considerably lower than of the merge sort. -- - But i propose for the Haskell-2 Standard Library sortBy :: Char - (a-a-Bool) - [a] - [a] --mode p xs -- sort list by ordering predicate p For example, sortBy 'm' () [2,1,3,1] -- [1,1,2,3] sortBy 'm' () [2,1,3,1] -- [3,2,1,1] sortBy 'q' () [2,1,3,1] -- [3,2,1,1] The mode 'm' reserves for the merge sort, 'q' for quick sort. -- - Regards. -- Sergey Mechveliani [EMAIL PROTECTED]
RE: sortings
[EMAIL PROTECTED] writes: To my Indeed, i voice for the merge sort ... Sigbjorn Finne [EMAIL PROTECTED] writes Have a look at the Util module in '-syslib misc', it provides a variety of sorting algorithms, including said merge sort. If you want others, check out Ralf Hinze's pages at http://www.informatik.uni-bonn.de/~ralf/ No, no. The question was not on the accessible variety of sorting programs. It was only which implementation ghc has to relate to the standard name `sort'. Right, but I don't think there's much hope of changing its implementation sometime this week (or the next..) just to accommodate the data sets you're sorting. Just trying to be helpful. --Sigbjorn
RE: Uncompiling internal names...
Alex Ferguson [EMAIL PROTECTED] writes:
...
Here's our convention for splitting up the interface file
name space:
d...dictionary identifiers
(local variables, so no name-clash worries)
Hrm. So, whence the trailing 0's? They all seem to be 0, so
admittedly this won't help me much anyway...
This is to ensure uniqueness, consider
class A a where {...}
data BC = ...
instance A BC where { ... }
class AB a where { ... }
data C = ...
instance AB C where { ... }
mapping both dicts to $dABC is a bad idea.
--Sigbjorn
RE: 2 questions: CVS Win32
Frank A. Christoph writes: ... I tried "cvs diff" from the fptools/ghc, but it doesn't seem to work for me. I get a series of messages: cvs server: Diffing . cvs server: Diffing compiler cvs server: Diffing compiler/absCSyn ... but no diffs. Having done that, I wondered if maybe there had been no recent changes, but when I do "cvs update" I see a few changes: .. What am I doing wrong? 'cvs diff -r HEAD' is your friend. Sigbjorn Finne wrote: Assuming you know the date at which you checked out a copy, something like the following should do the trick: cvs diff -D 01/30/99 -r HEAD This requires you to have two copies of your CVS tree though, the off-line one and one you can use to invoke 'cvs diff's from. Hm, OK, but what happens if there were multiple updates to the tree at Glasgow on that date, and my copy of it was not the last one? (Say there were updates at 4pm and 7pm, and I checked out my tree at 5pm.) The date can also include the time of day (see CVS docs)... anyway, this is not a problem for you since you're using anoncvs, which is only updated once every 24 hours (each 'night' at 22:00 GMT or so.) In fact, I don't see why I need a local copy of the tree at all. If I haven't changed the tree, then it should be equal to an old version of the one at Glasgow, so shouldn't I be able to generate a patch file just by supplying two version identifiers, and having the CVS server compute the differences locally at Glasgow? The thing I don't understand, I guess, is how to determine the version identifier for my tree. (Here's my situation: I have a GHC snapshot on my computer at home, but I typically access the Glasgow CVS server from work. I want to generate a patch file every few days so that I can fit the changes onto a floppy, carry it home and apply them manually to keep the tree up to date.) afaik, cvs doesn't let you do that - you need to be within a CVS tree in order to issue these commands. --Sigbjorn
RE: 2 questions: CVS Win32
Frank A. Christoph [mailto:[EMAIL PROTECTED]] writes: First, a CVS question. I am a real CVS novice so bear with me. I finally managed to use CVS to get the current 4.02 GHC distribution (and to compile it! :). Now, I understand how one can create recursive diffs between versions, but if I understand correctly, not every change counts as a "release version change", i.e., for the whole tree, not just a file. Is it possible to create a diff between my local tree and the current state of the tree in the repository? (I copied the tree elsewhere, somewhere I can't use CVS, and so I want to make a diff so that I don't have to copy the whole thing every time there is a change.) Assuming you know the date at which you checked out a copy, something like the following should do the trick: cvs diff -D 01/30/99 -r HEAD This requires you to have two copies of your CVS tree though, the off-line one and one you can use to invoke 'cvs diff's from. Second, I know that you need the Cygnus distribution to run GHC on Win32. My question is, do you also need it to run GHC-produced executables? Yes, afraid so. However, I'm currently testing some changes I've made to drop that DLL dependency. Included in that batch of changes is the support for generating using DLLs too. (prepare for ghc compiled binaries of less than 10k in size :-) --Sigbjorn
RE: getChar without pressing return?
Hi, have a look at the documentation for the IO library and its Handle buffering operations. To turn off the buffering of input, try doing something like the following, main = hSetBuffering stdin Nobuffering getChar = putChar Strictly speaking, Hugs is in the wrong here, but there's good reasons for it choosing to be so. --Sigbjorn Jan Laitenberger [EMAIL PROTECTED] writes: Hi, Does anyone know how I can get a character without the need of pressing the return key afterwards? main = do c - getChar putStr (c:"") Hugs returns the control back to the program as soon as a character was read - but ghc waits for a whole line to be finished... Thanks, Jan ___ '---|-- | __, _ _ EMail: [EMAIL PROTECTED] | / | / |/ | WWWeb: http://www.uni-passau.de/~laitenbe/ |/\_/|_/ | |_/ /| Laitenberger --(-|-- \|
RE: Is there anybody who can help me with this
Marc van Dongen [EMAIL PROTECTED] writes: Dear all, Hopefully somebody can help me out with this. I am looking for the file where the low level primops for operations on Integers are defined. I've had a look in Primops.h but that only includes cmpInteger# and a few friends. Where can I find the remaining ones? Any help would be greatly appreciated. This has probably been replied to by others off-line, but just in case it hasn't, rts/PrimOps.hc contains the other (non-inlinable ones.) Follow-ups to glasgow-haskell-bugs? --Sigbjorn
RE: Green Card and calling Haskell from C
Graeme E Moss [EMAIL PROTECTED] writes: In the on-line documentation for Green Card at: http://www.dcs.gla.ac.uk/fp/software/green-card/users-guide-9.html there is the following option for invoking green-card: --gc-safe Generates code that can use callbacks to Haskell (GHC only.) This makes the generated code slower. Does this allow C to call Haskell? No, this just generates code that is prepared for this to happen (using old GHC FFI lingo, the stub code calls out via _ccall_GC_ ) See the new FFI for mechanisms for calling Haskell functions from C. (HaskellDirect will provide tool support for the creation of C interfaces to Haskell libraries in the near future.) The HaskellDirect home page has got more info, http://www.dcs.gla.ac.uk/fp/software/hdirect/ hth, --Sigbjorn
RE: instance..= L a a
[EMAIL PROTECTED] writes: ghc-4 does not allow what ghc-3.02 did: ... instance Ring a = LeftModule a a where cMul = mul ghc-4 says Illegal instance declaration for `LeftModule a a' (There must be at least one non-type-variable in the instance head) If Haskell-2 is going to be this way, then this is somehow against the needs of algebra. I think this is a case of options vertigo - try compiling your source with '-fallow-overlapping-instances -optC-fallow-undecidable-instances' added to the command line. --Sigbjorn
