Re: new i/o library

Bulat Ziganshin wrote:

> moreover - we can implement locking as special "converter" type, that
> can be applied to any mutable object - stream, collection, counter.
> that allows to simplify implementations and add locking only to those
> Streams where we really need it. like these:
> 
> h <- openFD "test"
>        >>= addUsingOfSelect
>        >>= addBuffering 65536
>        >>= addCharEncoding utf8
>        >>= attachUserData dictionary
>        >>= addLocking

This is really nice - exactly what I'd like to see in the I/O library. 
The trick is making it perform well, though...  but I'm sure that's your 
main focus too.

Still, I'm not sure that putting both input and output streams in the 
same type is the right thing, I seem to remember a lot of things being 
simpler with them separate.

Cheers,
	Simon

UTF-8 decoding error

Hi,

with ghc-6.5.20060201 I get a "UTF-8 decoding error" for latin1 
characters in my string literals.

Do I have to change my sources or can I set a certain environment variable?

I have LANG=de_DE <at> euro and LC_CTYPE not set (which is ok for hugs)

Cheers Christian

Re[2]: new i/o library

Hello Simon,

Wednesday, February 01, 2006, 2:26:45 PM, you wrote:

SM> Bulat Ziganshin wrote:

i can now report about memory-mapped files in Windows. seems that
their support is not intended for implementing sequential file access
but exclusively for database-like files what be hold in memory as much
as possible and requires random access. at least, i used buffers of
64k and unmap them as soon as each buffer is filled. nevertheless,
windows delayed writing to disk already filled and unmapped buffers as
much as possible - even prefer to swap to disk OS and running programs
rather than flushung this data (when memory was filled by 80% with the
data of m/m file)! when i tried to sequentially read this file, the
results was slower than for simple read() calls, and i think that is
because data was not prefetched despite sequential access. i will
implement this stream type ultimately, but it will be more for some
special purposes than fir everyday use or an FD replacement

>> moreover - we can implement locking as special "converter" type, that
>> can be applied to any mutable object - stream, collection, counter.
>> that allows to simplify implementations and add locking only to those
>> Streams where we really need it. like these:
>> 
>> h <- openFD "test"
>>        >>= addUsingOfSelect
>>        >>= addBuffering 65536
>>        >>= addCharEncoding utf8
>>        >>= attachUserData dictionary

Re: Lexically scoped type variables

> | Simon Peyton-Jones wrote:
> | > I'm very interested to know whether you like it or hate it.
> | > In the latter case, I'd also like to know whether you also
> | > have programs that will be broken by the change.
> | 
> | I don't use GADTs yet and I assume this change will not (seriously)
> | break our code, but let me/us know which compiler we should use for
> testing.

I've installed now ghc-6.5.20060201 and I get quite a few errors of the 
form:

     A pattern type signature cannot bind scoped type variables `s'
       unless the pattern has a rigid type context

(and these are not always easy to fix in unknown non-haskell98 code by 
adding a "forall" and/or omitting the pattern type signatures)

Christian

You may try to translate the attached sources by:

   ghc --make -cpp -fallow-undecidable-instances -fglasgow-exts 
VariableList.hs

(and tell me how I should fix this)

_______________________________________________

RE: Re[2]: new i/o library

On 03 February 2006 08:34, Bulat Ziganshin wrote:

>>> moreover - we can implement locking as special "converter" type,
>>> that can be applied to any mutable object - stream, collection,
>>> counter. that allows to simplify implementations and add locking
>>> only to those Streams where we really need it. like these:
>>> 
>>> h <- openFD "test"
>>>        >>= addUsingOfSelect
>>>        >>= addBuffering 65536
>>>        >>= addCharEncoding utf8
>>>        >>= attachUserData dictionary
>>>        >>= addLocking
> 
>> This is really nice - exactly what I'd like to see in the I/O
>> library. The trick is making it perform well, though...  but I'm
>> sure that's your main focus too.
> 
> basically idea is very simple - every stream implements the Stream
> interface, what is clone of Handle interface. Stream transformers is
> just a types what has Stream parameters and in turn implement the same
> interface. all Stream operations are translated to calls of inner
> Stream. typical example:
> 
> data WithLocking h = WithLocking h (MVar ())

There's a choice here; I did it with existentials:

   data ThreadSafeStream = forall h . Stream h => TSStream h !(MVar ())
   instance Stream ThreadSafeStream where ...

Re: UTF-8 decoding error

Christian Maeder wrote:

> with ghc-6.5.20060201 I get a "UTF-8 decoding error" for latin1 
> characters in my string literals.
> 
> Do I have to change my sources or can I set a certain environment variable?
> 
> I have LANG=de_DE <at> euro and LC_CTYPE not set (which is ok for hugs)

GHC is now expected source files to be UTF-8 only.  I really did this as 
an experiment to see if anyone complained, because it will be more work 
to implement other encodings.  You're the second person to notice this. 
  So - do you need Latin-1, or could you use UTF-8?

If you're using emacs, it's pretty easy to default to UTF-8 for haskell 
source files, BTW.  Just add this to your .emacs:

(modify-coding-system-alist 'file "\\.l?hs\\'" 'utf-8)

Cheers,
	Simon

Re: new i/o library

Simon Marlow wrote:

> -- | Takes an output stream and an input stream, and pipes all the
> -- data from the former into the latter.
> streamConnect :: (OutputStream o, InputStream i) => o -> i -> IO ()

That's the wrong way around, of course   It pipes everything from the 
input stream to the output stream.

Cheers,
	Simon

Re: Linking with C++ produced by Visual Studio .NET on Windows XP?

Cyril Schmidt wrote:
> I added this to the FAQ list; please feel free to elaborate and correct.
> 
> Linking to Visual Studio-generated code would be much easier if GHC were 
> able
> to use Visual C++ as backend, instead of gcc (even Visual Haskell at the 
> moment
> relies on gcc for C compilation).
> 
> I have no idea, though, how much work it would be to make GHC able to 
> compile
> via Visual C++.
> 

	From what I remember of Simon's talk at ICFP04, at least the 
evil-mangler would probably need an overall.

Re: Linking with C++ produced by Visual Studio .NET on Windows XP?

I think that the C backend is heavily dependent on various GCC pragmas
but it should be relatively easy to do assembly backend that produces
MASM code.

Cheers,
   Krasimir

2006/2/3, Geoffrey Alan Washburn <geoffw <at> cis.upenn.edu>:
> Cyril Schmidt wrote:
> > I added this to the FAQ list; please feel free to elaborate and correct.
> >
> > Linking to Visual Studio-generated code would be much easier if GHC were
> > able
> > to use Visual C++ as backend, instead of gcc (even Visual Haskell at the
> > moment
> > relies on gcc for C compilation).
> >
> > I have no idea, though, how much work it would be to make GHC able to
> > compile
> > via Visual C++.
> >
>
>        From what I remember of Simon's talk at ICFP04, at least the
> evil-mangler would probably need an overall.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

Re: UTF-8 decoding error

Simon Marlow wrote:
>  So - do you need Latin-1, or could you use UTF-8?

I'm not amused to change the encoding of many haskell source files 
(particular of those that are not mine).

These files can then no longer be compiled by earlier ghcs (though I 
don't understand, how ghc-6.4.1 recognises the lexical error).

I'm tempted to replace "ä" bei "\228" in literals. What does haddock do 
with utf-8 in comments? Will DrIFT -- using read- and writeFile -- still 
work correctly?

Cheers Christian