April 2002 - Libraries

RE: BER and LDAP Libraries
by Simon Marlow 30 Apr '02

30 Apr '02

> I am about to update our library for BER (Basic Encoding > Rules). I have > read http://www.haskell.org/~simonmar/libraries/libraries.html. > > I think it should be called Network.BER. That's fine. > I don't have any strong views on licensing and it looks like BSD would > cause the least problems. The license is entirely up to you, but one practical thing to bear in mind is that we're going to keep licenses the same within a given package (i.e. libraries/base, libraries/network etc.) so if you envisage your code being absorbed into libraries/network at some point then this will be easier if you pick the same license (i.e. BSD). > I assume it should be classified as experimental. This just affects how often you can change the interface. Best to stick with experimental until it's been out in the wild a while. > I am using CVS. Could someone tell me how I get the string > > -- $Id: libraries.sgml,v 1.4 2001/07/05 13:52:49 simonmar Exp $ > > put into the recommended header (see below)? Actually I've just removed all these from fptools/libraries on the grounds that they were confusing and didn't really serve the purpose they were intended to, so don't worry about the $Id$ string unless you have a good reason for wanting one. Cheers, Simon

1 0

BER and LDAP Libraries
by dominic.j.steinitz＠britishairways.com 30 Apr '02

30 Apr '02

I am about to update our library for BER (Basic Encoding Rules). I have read http://www.haskell.org/~simonmar/libraries/libraries.html. I think it should be called Network.BER. I don't have any strong views on licensing and it looks like BSD would cause the least problems. I assume it should be classified as experimental. I also assume it is non-portable as uses existential types and Words and Bits. I am using CVS. Could someone tell me how I get the string -- $Id: libraries.sgml,v 1.4 2001/07/05 13:52:49 simonmar Exp $ put into the recommended header (see below)? Thanks, Dominic. ------------------------------------------------------------------------------ -- Module : module-- Copyright : (c) author year -- License : license-- -- Maintainer : libraries(a)haskell.org | email-address -- Stability : experimental | provisional | stable -- Portability : portable | non-portable (reason(s))-- -- $Id: libraries.sgml,v 1.4 2001/07/05 13:52:49 simonmar Exp $---- Description ----------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- Save time by using an eTicket and our Self-Service Check-in Kiosks. For more information go to http://www.britishairways.com/eservice1

2 1

소비자의 권리를 아세요? 지금 바로 찾으세요^^ [홍보홍보]
by 다이오마트 20 Apr '02

20 Apr '02

소비자 중심주의 다이오마트(DIOMART) 소비자 중심주의 다이오마트(DIOMART) 소비자의 권리를 모두 찾아드리는 세계 최초 최고의 시스템 다이오마트입니다. 안녕하세요? 소비자 권리를 완벽하게 찾아드리는 다이오마트 장도환입니다. 매달 소비생활을 하시면서 소비자의 권리를 얼마나 찾고 계신가요? 신용카드나 쇼핑몰에서 구매를 하셨을 때 적립되는 포인트나 적립금을 현금으로 받아보신적이 있으신가요? 아마도 없으실 겁니다. 형식적으로는 고객을 생각한다고 제도를 만들어놓고 실제로는 거의 지급을 하지 않는 것이 현실입니다. 하지만 이제부터는 소비자의 모든 권리를 저희 다이오마트가 찾아드립니다. 생활전반에 걸친 소비를 하시면서 얼마든지 현금으로 되돌려 받는 시스템입니다. 그것도 본인이 구매하는 것에 대한 것만 받는 것이 아니라 많은 회원들이 구매하는 포인트를 모아모아서 본인이 돌려 받는 것입니다. 이제는 언제 어디서 어떤 소비를 하시더라도 소비자체가 곧 수입이 되는 시대가 왔습니다. 저희 다이오마트는 또한 추천인제도를 두어 추천인이 구매하는 포인트의 10%를 본인이 돌려 받게 됩니다. 내가 주변에 추천을 해서 그 분들이 구매를 하시게 될 경우 나에게 매달 현금으로 되돌아 오는 시스템입니다. 지금 현재 저희 다이오마트와 제휴한 삼성몰, 인터파크, Yes24 온라인서점,아이엠코리아등의 대형 쇼핑몰에서 구매를 하시든 각기 현금으로 되돌려 받으시게 됩니다. 또한 링크플라워 꽃배달 서비스, 유니코21 보험 서비스, 전용선 메가패스, 위성TV 스카이 라이프 등을 이용하셔도 현금으로 적립시켜 드립니다. 향후 저희 다이오마트는 미국,일본,대만,중국 등에도 진출하게 됩니다. 좁은 국내 시장에 머무르는 것이 아니라 전세계를 대상으로 합니다. 원래 저희 다이오마트가 미국에 기반을 둔 회사이므로 해외진출은 쉽게 진전이 됩니다. 뿐만 아니라 향후 집앞의 미용실이나 식당, 학원, 부동산, 슈퍼 등도 저희 가맹점으로 들어오게 됩니다. 그냥 평소의 소비생활을 단지 저희 다이오마트를 통해서만 하신다고 해도 매달 25%의 캐시백을 받으시게 됩니다. 또한 다이오마트 신용카드가 발급이 되면 어디서 사용을 하시든 신용카드 적립금을 모두 현금으로 되돌려 드립니다. 또한 저희 다이오마트 회원이 되시면 자동으로 3*15매트릭스 시스템에 자리를 잡아 나중에 15단계 회원들이 구매하는 포인트까지 누적하여 지급이 됩니다. 만약 본인 하위에 15단계가 다 차게 된다면 매달 200억의 수입도 바라보게 됩니다. 200억은 조금 힘들다 하더라도 최소한 그 천분의 일은 누구나 가능하게 될 것입니다. 지금 바로 가입하시는 것이 유리하답니다. 회원가입하기:http://www.e-diolink.com/diomart/diomart7.htm 추천인 아이디:205701(추천인 아이디를 반드시 기재하셔야 가입이 됩니다.) 가입하신 후 저희 커뮤니티로 오시면 자세한 홍보방법과 노하우를 지원해 드림으로써 누구나 쉽게 수입이 될 수 있도록 도와 드립니다. 다이오마트 홈:http://www.diomart.com 개인홈:http://e-diolink.com/205701 다사모 커뮤니티:http://freechal.com/diolinkkorea O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다 O e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다 O수신거부를 원하시면수신거부 해 주세요.정보를 원치 않는 분께는 대단히 죄송 합니다.

1 0

Re: Numeric Classes Quibble
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-09 08:52, Alastair Reid wrote: >> Currently 'floor' doesn't work on Integers. I think this is undesirable. > >I missed the motivation - can you elaborate? I'd like to be able to write polymorphic numeric functions over Real. Here's the snippet that gave rise to this: instance (HasLeapSecondsRule m,Real a) => MonadIsA m (UTCTime a) (Time a) where { getConvert (MkPointWrapper t) = do { lsr <- getLeapSecondsRule; let { days = invertFuncWithApprox lsr (floor (toRational t)) (intdiv t 86400.002); -- 2ms approx secs = t - fromInteger (lsr days); }; return (MkUTCTime days secs); }; }; I'm using a fairly trivial workaround, (floor (toRational t)). But ideally I could just write (floor t). >Or, to put it another way, wouldn't floor always act as the identity? Not over all Real, obviously. >What would this buy us? Generality? -- Ashley Yakeley, Seattle WA

1 0

Re: Numeric Classes Quibble
by Alastair Reid 09 Apr '02

09 Apr '02

> Currently 'floor' doesn't work on Integers. I think this is undesirable. I missed the motivation - can you elaborate? Or, to put it another way, wouldn't floor always act as the identity? What would this buy us? -- Alastair Reid

1 0

RE: Numeric Classes Quibble
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-09 00:58, Simon Peyton-Jones wrote: >I don't think we can run around changing the Haskell 98 class >structure, imperfect though it may be. Simon I suppose not. Save it for whenever the standard libraries are to be overhauled. -- Ashley Yakeley, Seattle WA

1 0

RE: Numeric Classes Quibble
by Simon Peyton-Jones 09 Apr '02

09 Apr '02

I don't think we can run around changing the Haskell 98 class structure, imperfect though it may be. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 09 April 2002 04:58 | To: Libraries for Haskell List | Subject: Numeric Classes Quibble | | | Currently 'floor' doesn't work on Integers. I think this is | undesirable. | | I submit that all the members of RealFrac: 'properFraction', | 'truncate', | 'round', 'ceiling' and 'floor' be moved up to Real. I can already | construct them for Integral (the other subclass of Real): | | properFraction' :: (Integral a,Integral b) => a -> (b,a); | properFraction' a = (fromIntegral a,0); | | (all the others are derived) | | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries |

1 0

Numeric Classes Quibble
by Ashley Yakeley 08 Apr '02

08 Apr '02

Currently 'floor' doesn't work on Integers. I think this is undesirable. I submit that all the members of RealFrac: 'properFraction', 'truncate', 'round', 'ceiling' and 'floor' be moved up to Real. I can already construct them for Integral (the other subclass of Real): properFraction' :: (Integral a,Integral b) => a -> (b,a); properFraction' a = (fromIntegral a,0); (all the others are derived) -- Ashley Yakeley, Seattle WA

1 0

RE: String type in Socket I/O
by Simon Marlow 08 Apr '02

08 Apr '02

> I am writing an HTTP client-side library, using the > SocketPrim library. > During the implementation of Base64 encode/decode I began to > have some > doubts over the use of the Char type for socket I/O. > > As far as I can tell, "sendTo" and "recvFrom" are simply > handles on the > underlying OS calls. My winsock2.h file tells me the data > passed into and > received from these functions are C style chars, 8 bits each. > In unix these > functions (sys/sockets.h) appear to use a C void pointer. > Finally I notice > that the Haskell98 report defines Haskell Char as a Unicode > char (which I > figure isn't guaranteed 8 bits). > > So I am curious, what happens when I send these unicode > Haskell chars to the > SocketPrim.sendTo function? My current guess is that the low > 8 bits of each > Char become a C style char. That's what happens in GHC, but as you correctly point out this is wrong. The real problem is twofold: GHC doesn't have proper support for Unicode encoding/decoding at the I/O interface, and we don't have an "approved" way to write other kinds of data into a file. In GHC we currently have this interface (not in a released version yet) in the module Data.Array.IO: hGetArray :: Handle -> IOUArray Int Word8 -> Int -> IO Int hPutArray :: Handle -> IOUArray Int Word8 -> Int -> IO () and there's also a Binary I/O library I've been working on that can be used for reading/writing Word8s and other low-level kinds of data in a predictable way (I guess we should discuss what the interface to Data.Binary should look like at some point). I'd also be happy to add hPutWord8 :: Handle -> Word8 -> IO () hGetWord8 :: Handle -> IO Word8 to System.IO if people think this is the right thing to do. Cheers, Simon

1 0

Re: String type in Socket I/O
by dominic.j.steinitz＠britishairways.com 08 Apr '02

08 Apr '02

Having written a Haskell LDAP interface, this is something that worried me but I never got to the bottom of. I've cross-posted this to haskell (hopefully the right place). There was some discussion of replacing Char by a type for raw bytes / octets but I'm not sure what happened to it. Dominic. "Warrick Gray" <oinutter(a)hotmail.com>@haskell.org on 07/04/2002 13:31:41 Sent by: libraries-admin(a)haskell.org To: libraries cc: bcc: Subject: String type in Socket I/O Hi all, I am writing an HTTP client-side library, using the SocketPrim library. During the implementation of Base64 encode/decode I began to have some doubts over the use of the Char type for socket I/O. As far as I can tell, "sendTo" and "recvFrom" are simply handles on the underlying OS calls. My winsock2.h file tells me the data passed into and received from these functions are C style chars, 8 bits each. In unix these functions (sys/sockets.h) appear to use a C void pointer. Finally I notice that the Haskell98 report defines Haskell Char as a Unicode char (which I figure isn't guaranteed 8 bits). So I am curious, what happens when I send these unicode Haskell chars to the SocketPrim.sendTo function? My current guess is that the low 8 bits of each Char become a C style char. My base64 encoding and decoding functions sort of make this assumption, by ripping out the low 8 bits of chars before encoding this binary representation (3x8bit chars become 4x6bit base64 chars). So far everything works fine, but is this approach going to break in the near future? What I would like to see are socket functions that do not introduce this extra level of binary indirection, perhaps using a ByteArray, or Word8 (as I see has previously been discussed - http://www.haskell.org/pipermail/libraries/2001-August/000482.html) How realistic is this? Warrick. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/libraries ------------------------------------------------------------------------------------------------- Save time by using an eTicket and our Self-Service Check-in Kiosks. For more information go to http://www.britishairways.com/eservice1

1 0