- ghc-tickets - Haskell.org

Re: [GHC] #2648: Report out of date interface files robustly
by GHC 23 Apr '13

23 Apr '13

#2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by liyang): * failure: None/Unknown => GHCi crash * component: Compiler => GHCi Comment: For what it's worth, I don't think I have ever seen this when compiling the project. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2648#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2648: Report out of date interface files robustly
by GHC 23 Apr '13

23 Apr '13

#2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) * failure: => None/Unknown * version: 6.8.3 => 7.6.3 Comment: This is biting me on a regular basis when I {{{:reload}}} a fairly large project in GHCi. It didn't seem to crop up so often (at all?) back when I was still using 7.4.2… -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2648#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 23 Apr '13

23 Apr '13

#7606: Stride scheduling for Haskell threads with priorities -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #7857: GHC says there are unsafe overlapping instances, but only one instance applies
by GHC 23 Apr '13

23 Apr '13

#7857: GHC says there are unsafe overlapping instances, but only one instance applies -----------------------------+---------------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code rightfully does not compile: {{{ import Text.Printf f :: a -> b f = undefined g i = f $ printf "" i }}} However, the error message is a very surprising one: {{{ test.hs:6:1: Unsafe overlapping instances for PrintfType (t -> a0) arising from the ambiguity check for `g' The matching instance is: instance [safe] (PrintfArg a, PrintfType r) => PrintfType (a -> r) -- Defined in `Text.Printf' It is compiled in a Safe module and as such can only overlap instances from the same module, however it overlaps the following instances from different modules: When checking that `g' has the inferred type `forall a b t. PrintfType (t -> a) => t -> b' Probable cause: the inferred type is ambiguous }}} What I find surprising is the claim that there are overlapping instances, followed by a list of instances that clearly does not have any overlaps. For comparison, changing the definition of g to be {{{ g = f . printf "" }}} gives a much more reasonable error: {{{ test.hs:6:9: No instance for (PrintfArg a0) arising from a use of `printf' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance [safe] PrintfArg Char -- Defined in `Text.Printf' instance [safe] PrintfArg Double -- Defined in `Text.Printf' instance [safe] PrintfArg Float -- Defined in `Text.Printf' ...plus 12 others In the second argument of `(.)', namely `printf ""' In the expression: f . printf "" In an equation for `g': g = f . printf "" }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5682: Properly parse kind operators (from promoted type operators)
by GHC 22 Apr '13

22 Apr '13

#5682: Properly parse kind operators (from promoted type operators) -------------------------------------+-------------------------------------- Reporter: lunaris | Owner: dreixel Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Keywords: PolyKinds, ghc-kinds | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------------+-------------------------------------- Changes (by elliottt): * cc: trevor@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5682#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7818: Cost of STACK object should be attributed to CCCS at time of thread creation
by GHC 22 Apr '13

22 Apr '13

#7818: Cost of STACK object should be attributed to CCCS at time of thread creation -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Component: Profiling Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Right now, we always charge STACK objects to the SYSTEM cost centre. I think it makes more sense for us to charge them to the CCCS responsible for creating the thread: it’s more specific and we don’t really lose anything in the trade (it’s easy to ask for a per-closure-type profile). Here’s a strawman patch (obviously this doesn’t do anything when not compiling the profiling way.) Are there any objections? {{{ diff --git a/rts/Threads.c b/rts/Threads.c index b617616..76ac705 100644 --- a/rts/Threads.c +++ b/rts/Threads.c @@ -84,7 +84,7 @@ createThread(Capability *cap, W_ size) stack_size = round_to_mblocks(size - sizeofW(StgTSO)); stack = (StgStack *)allocate(cap, stack_size); TICK_ALLOC_STACK(stack_size); - SET_HDR(stack, &stg_STACK_info, CCS_SYSTEM); + SET_HDR(stack, &stg_STACK_info, cap->r.rCCCS); stack->stack_size = stack_size - sizeofW(StgStack); stack->sp = stack->stack + stack->stack_size; stack->dirty = 1; @@ -575,7 +575,11 @@ threadStackOverflow (Capability *cap, StgTSO *tso) chunk_size * sizeof(W_)); new_stack = (StgStack*) allocate(cap, chunk_size); - SET_HDR(new_stack, &stg_STACK_info, CCS_SYSTEM); +#ifdef PROFILING + SET_HDR(new_stack, &stg_STACK_info, old_stack->header.prof.ccs); +#else + SET_HDR(new_stack, &stg_STACK_info, CCCS_SYSTEM); +#endif TICK_ALLOC_STACK(chunk_size); new_stack->dirty = 0; // begin clean, we'll mark it dirty below }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7820: Installing profiling library BREAKS non-profiling executable
by GHC 22 Apr '13

22 Apr '13

#7820: Installing profiling library BREAKS non-profiling executable --------------------------+------------------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: profiling Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I am trying to work through problems with different GHC "ways" so that I can broadly deploy a library of foreign primops for lockfree data structures. Here's the package I am testing at the moment: https://github.com/rrnewton/haskell-lockfree- queue/tree/5d990fe43a983fc5ed32c3f58cb2e59df71b00b6/AtomicPrimops Here is a recipe for reproducing the bug from within that directory. Both of these build modes work FINE: (cabal install --enable-library-profiling; cd testing; make prof; ./Test_prof.exe) (cabal install --disable-library-profiling; cd testing; make; ./Test_threaded.exe) That is, building both library and executable with profiling, or without profiling, works fine. But then this creates an executable that segfaults: (cabal install --enable-library-profiling; cd testing; make; ./Test_threaded.exe) At runtime the call to the .cmm-defined foreign primop just returns zero, and then the process segfaults when it tries to use that as a Haskell value. But my understanding is that --enable-library-profiling should just add extra binaries to .cabal and NOT change the behavior of the non-profiling binaries. Yet I can confirm that I see slightly different binary sizes with the non- profiling .o and .a files installed in ~/.cabal/lib depending on whether --enable-library-profiling is activated. Perhaps this in itself is a cabal bug, but I haven't tracked down exactly what the difference is yet. I have confirmed the above behavior under: * Mac OS (ghc 7.4.2 and 7.6.2) * Linux, RHEL 6 (ghc 7.4.2 and 7.6.2) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7849: Error on pattern matching of an existential whose context includes a type function
by GHC 22 Apr '13

22 Apr '13

#7849: Error on pattern matching of an existential whose context includes a type function -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GADTs #-} module Ex where import Data.IORef class SUBJ subj where type SUBJ_Obs subj :: * unsubscribe' :: subj -> SUBJ_Obs subj -> IO () data ASubj obs = forall subj. (SUBJ subj, SUBJ_Obs subj ~ obs) => ASubj subj -- data ASubj obs = forall subj. (SUBJ subj) => ASubj subj (obs -> SUBJ_Obs subj) class OBS obs where subscribed :: obs -> ASubj obs -> IO () withdraw :: obs -> IO () -- The implementation of Obs data Obs = Obs{obs_subjects :: IORef [ASubj Obs]} instance OBS Obs where subscribed obs subj = modifyIORef (obs_subjects obs) (subj:) withdraw obs = do subjs <- readIORef (obs_subjects obs) writeIORef (obs_subjects obs) [] mapM_ (\ (ASubj subj) -> unsubscribe' subj obs) subjs -- mapM_ (\ (ASubj subj cast) -> unsubscribe' subj (cast obs)) subjs }}} gives a rather obscure type error {{{ Couldn't match type `b0' with `()' `b0' is untouchable inside the constraints (SUBJ subj, SUBJ_Obs subj ~ Obs) bound at a pattern with constructor ASubj :: forall obs subj. (SUBJ subj, SUBJ_Obs subj ~ obs) => subj -> ASubj obs, in a lambda abstraction In the pattern: ASubj subj In the first argument of `mapM_', namely `(\ (ASubj subj) -> unsubscribe' subj obs)' In a stmt of a 'do' block: mapM_ (\ (ASubj subj) -> unsubscribe' subj obs) subjs -} }}} It is not even clear what b0 is: the code has no type variable named b. Incidentally, if I use the explicit cast (as in the commented out declaration of ASubj) and change the last line of withdraw accordingly (as shown in the commented out line), the code compiles. It seems that what I am trying to accomplish is reasonable. Incidentally, why GHC insists on the extension GADTs given that I already specified ExistentialQuantification? It seems when opening amn existential GADTs extension must be present. It seems ExistentialQuantification no longer has any point? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7786: strange errors when deducing constraints
by GHC 22 Apr '13

22 Apr '13

#7786: strange errors when deducing constraints -----------------------------+---------------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Please load attached file in ghci and observe the resulting error message. I have added my commentaries inline to what appears fishy to me. All may technically be ok, but look quite confusing. {{{ [1 of 1] Compiling Main ( pr7786.hs, interpreted ) pr7786.hs:74:22: Couldn't match type `Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv' with 'Empty [KeySegment] Inaccessible code in a pattern with constructor Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k), in a pattern binding in 'do' block }}} Yes, ok, (Nil :: Sing Empty) does not unify with (forall xxx. Nil :: Sing xxx). {{{ Relevant bindings include addSub :: Database inv -> Sing [KeySegment] k -> Database sub -> Maybe (Database (BuriedUnder sub k inv)) (bound at pr7786.hs:74:1) db :: Database inv (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k (bound at pr7786.hs:74:11) sub :: Database sub (bound at pr7786.hs:74:13) In the pattern: Nil In the pattern: Nil :: Sing xxx In a stmt of a 'do' block: Nil :: Sing xxx <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db) pr7786.hs:78:31: Could not deduce (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv ~ 'Empty [KeySegment]) from the context (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv ~ 'Empty [KeySegment]) }}} This one is highly disturbing. I think the user should never see such a message. Scary. ''This is the reason for the ticket''. {{{ bound by a pattern with constructor Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k), in a pattern binding in 'do' block at pr7786.hs:74:22-24 Relevant bindings include addSub :: Database inv -> Sing [KeySegment] k -> Database sub -> Maybe (Database (BuriedUnder sub k inv)) (bound at pr7786.hs:74:1) db :: Database inv (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k (bound at pr7786.hs:74:11) sub :: Database sub (bound at pr7786.hs:74:13) In the second argument of `($)', namely `Sub db k sub' In a stmt of a 'do' block: return $ Sub db k sub In the expression: do { Nil :: Sing xxx <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db); return $ Sub db k sub } Failed, modules loaded: none. }}} '''Now comment line 74 and uncomment l. 75 and reload:''' {{{ pr7786.hs:75:22: Couldn't match type `Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv' with `Intersect [KeySegment] (BuriedUnder sub1 k1 ('Empty [KeySegment])) inv1' }}} Hmm, I vaguely understand why those new degrees of freedom arise. {{{ NB: `Intersect' is a type function, and may not be injective }}} Probably irrelevant, no need to backwards guess here, as we have -XScopedTypeVariables turned on. {{{ The type variables `sub', `k', `inv' are ambiguous Expected type: Sing (Inventory [KeySegment]) (Intersect [KeySegment] (BuriedUnder sub1 k1 ('Empty [KeySegment])) inv1) Actual type: Sing (Inventory [KeySegment]) (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv) Relevant bindings include addSub :: Database inv1 -> Sing [KeySegment] k1 -> Database sub1 -> Maybe (Database (BuriedUnder sub1 k1 inv1)) (bound at pr7786.hs:74:1) db :: Database inv1 (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k1 (bound at pr7786.hs:74:11) sub :: Database sub1 (bound at pr7786.hs:74:13) In the pattern: Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) In a stmt of a 'do' block: Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db) In the expression: do { Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db); return $ Sub db k sub } Failed, modules loaded: none. }}} '''Now comment line 75 and uncomment l. 76 and reload:''' {{{ [1 of 1] Compiling Main ( pr7786.hs, interpreted ) pr7786.hs:76:51: Couldn't match type `Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv' with 'Empty [KeySegment] Expected type: Sing (Inventory [KeySegment]) ('Empty [KeySegment]) Actual type: Sing (Inventory [KeySegment]) (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv) }}} Err... But (Nil :: Sing Empty) is ''exactly'' the annotation on the Nil constructor in the GADT definition! {{{ Relevant bindings include addSub :: Database inv -> Sing [KeySegment] k -> Database sub -> Maybe (Database (BuriedUnder sub k inv)) (bound at pr7786.hs:74:1) db :: Database inv (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k (bound at pr7786.hs:74:11) sub :: Database sub (bound at pr7786.hs:74:13) In the first argument of `return', namely `(buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db)' In a stmt of a 'do' block: Nil :: Sing Empty <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db) In the expression: do { Nil :: Sing Empty <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db); return $ Sub db k sub } Failed, modules loaded: none. }}} '''Now comment line 76 and uncomment l. 77 and reload:''' All is dandy! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7856: matter for release 7.6.3 relieved
by GHC 22 Apr '13

22 Apr '13

#7856: matter for release 7.6.3 relieved -----------------------------+---------------------------------------------- Reporter: AngelaRamirez | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Безопасность и абсолютная конфиденциальность на web-сайте секс-услуг. В наше время интернет – это не просто средство, предназначенное для обмена данными, это еще и хороший помощник всем, кто желает развлечься. Web-порталы, посвященные предоставлению секс-услуг, способны сделать досуг незабываемым и максимально интересным. Ведь не существует границы фантазиям. На предоставляющем услуги интимного характера веб-портале подобраны наилучшие проститутки киева. Здесь также есть возможность рассмотреть любую девушку и ознакомиться с ценой, правилами и предлагаемыми услугами. Конечно же, к интим-услугам проститутки киев это будет либо какой-нибудь другой город захотят прибегнуть многие мужчины. А причин для этого может быть огромнейшее множество: - избавиться от комплексов;- отдохнуть телом и душой;- приобрести новый опыт в сексе;- сделать сюрприз партнерам либо другу; - ощутить себя желанным;- заняться своего рода экспериментами. Некоторые гости столицы, приезжая сюда для ознакомления с местными достопримечательностями либо по делам стремятся воспользоваться сексуальными услугами. Ведь Киев проститутки в любое время составят приятную и веселую компанию и не дадут гостям умирать от скуки. Они без проблем смогут приехать на час, два либо же остаться на всю ночь. Для того, чтобы воспользоваться услугами прекрасных и красивых дам достаточно лишь посетить web-сайт, отыскать приглянувшуюся девушку, а затем связаться по контактному телефону с представителем. Потребуется также указать, где вы предпочитаете с девушкой встретиться и период времени, в течение которого вы будете пользоваться сексуальными услугами. Все пожелания будут строго соблюдены. Огромнейшим плюсом данного сервиса считается то, что если вдруг необходимы проститутки в киеве, то не понадобится в поисках сомнительных услуг куда-либо выезжать. В любое время можно воспользоваться услугами надежной и проверенной компании. Имея какое-то количество свободного времени, возможно рассмотреть все анкеты проституток киева. Следовательно, по каким-то определенным показателям возможно подобрать девочек, к интим-услугам которых можно будет прибегать постоянно. Оказывающие интим-услуги компании отводят уровню обслуживания важную роль. Мужчина должен оставаться доволен всегда. Только лишь в этом случае приглашать девочек он станет вновь. Если же мужчину очень заинтересовала какая-то [http://escort-models.com проститутка киев] посещает он периодически, то и к услугам он ее станет прибегать всегда. Притом ему могут предоставляться скидки. Востребованность интим-услуг постоянно возрастает. Это понятно, потому как сегодня самая древняя профессия стала более доступной. Многие интернет-страницы пестрят самыми разнообразными разновидностями интимных удовольствий, к примеру, веб-камеры, чаты. Однако нет ничего лучше вызова девушки на дом, где есть возможность как отдохнуть телом, так и мило пообщаться с привлекательной и приятной девушкой. Можно быть уверенным в том, что при обращении в надежное и проверенное агентство, услуги осуществляются на должном уровне, вечер будет потрясающим, и все данные о клиенте останутся конфиденциальными. Воспользоваться услугами проститутки можно для себя, а можно также сделать приятное партнерам по бизнесу либо же скучающему другу. Подобные сюрпризы будут высоко оценены. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7856> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0