Re: [Haskell-cafe] Performance question

2010-03-18 Thread Andrey Sisoyev

Right now, the bottleneck of my program is in binarySearch', the function
must be called a few billion times.
Do you have any ideas on how to improve the performance of this function?

Bast solution for speeding up is to write it in assembler!

Ragards, Andrey
-- 
View this message in context: 
http://old.nabble.com/Performance-question-tp27949969p27950864.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)

2010-03-06 Thread Andrey Sisoyev

Probably, a considerable part of beginner-programmers (also in our
community), who are interested in GPL ideas, may want to use some similar
GPL clarification: about being dependent work is not equal to derived
work.

I guess, an article in haskell-wiki (clarifying situation with GPL) would be
nice to have.

IMHO they shouldn't equalize terms dependent and deriving - that's just
silly. 

Reagards,
Andrey


Rafael Almeida wrote:
 
 On Fri, Mar 5, 2010 at 2:59 PM, Job Vranish job.vran...@gmail.com wrote:
 
 Linux license specifically single that case out of the license
 restrictions. From the COPYING file in linux's source:
 
NOTE! This copyright does *not* cover user programs that use kernel
  services by normal system calls - this is merely considered normal
 use
  of the kernel, and does *not* fall under the heading of derived
 work.
  Also note that the GPL below is copyrighted by the Free Software
  Foundation, but the instance of code that it refers to (the Linux
  kernel) is copyrighted by me and others who actually wrote it.
 
  Also note that the only valid version of the GPL as far as the kernel
  is concerned is _this_ particular version of the license (ie v2, not
  v2.2 or v3.x or whatever), unless explicitly otherwise stated.
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 

-- 
View this message in context: 
http://old.nabble.com/GPL-answers-from-the-SFLC-%28WAS%3A-Re%3A-ANN%3A-hakyll-0.1%29-tp27783997p27803729.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] How do you rewrite your code?

2010-03-02 Thread Andrey Sisoyev

Speaking about macrorewriting, I do prefer to break big modules (prototypes)
into smaller ones, then step by step separate them into a set of minimally
dependent and highly general cabal packages.

As for microrewriting I find it to be a good practice to explicate all
possible (programmable or Real World) errors into dedicated ADT
constructions. This draws enough attention to every error to guarantee that
there is no missed risks and protection is good enough.

Regards, Andrey
-- 
View this message in context: 
http://old.nabble.com/How-do-you-rewrite-your-code--tp27760033p27760681.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


[Haskell-cafe] ANNOUNCE: Cardinality-0.1

2010-01-20 Thread Andrey Sisoyev

Hi everybody!

I developed a new package that you may find handy, when transforming
containers.
With this package we now have unified ways to make safe transforms from a
- Maybe (to a) and from - Maybe to between simple containers like [],
Maybe, Identity, Map.

Test set that returns all True:

((sContTransT []) :: Maybe (Maybe Int)) == Just Nothing
((sContTrans  ()) :: Maybe (Maybe Int)) == Just Nothing
((sContTransT [1]) :: (Maybe (Maybe Int))) == Just (Just 1)
((sContTransT [1, 2]) :: (Maybe (Maybe Int))) == Nothing
((sContTransT $ Just Hello) :: (Maybe (Identity String))) == Just
(Identity Hello)
((sContTransT [Hello]) :: Maybe (Identity String)) == Just (Identity
Hello)
((sContTransT (EmptySet :: EmptySet String)) :: (Maybe [String])) == Just []
((sContTransT Hello) :: Maybe (EmptySet Char)) == Nothing
((sContTransT (key, elem)) :: Maybe (Map String String)) == Just
(singleton key elem)
((sContTrans [(key1, elem1), (key2, elem2)]) :: Maybe (Map String
String)) == Just (fromList [(key1, elem1), (key2, elem2)])
((sContTrans (EmptySet :: EmptySet (String, String))) :: Maybe (Map String
String)) == Just empty
((sContTrans []) :: Maybe ()) == Just ()
((sContTrans (NEL 'H' i!)) :: Maybe String) == Just Hi! --
Data.NeverEmptyList
((sContTrans ()) :: Maybe String) == Just 
((sContTrans ) :: Maybe (Identity Char)) == Nothing
((sContTrans Hi!) :: Maybe ()) == Nothing

Package is to be found here: http://hackage.haskell.org/package/Cardinality
It dances around cardinality - a measure of of the number of elements of the
set (container); and cardinality constraint of the container. Cardinality
constraints:
** (): 0 elements
** Identity a: 1 element
** (Maybe a): 0..1 elements
** [a]: 0..Infinity elements
** Map k e: 0..Infinity elements
** (a,a,a): 3 elements

I also introduced 2 containers (which I found strange not to be in the
Prelude):
** data EmptySet a = EmptySet -- (0 elements)
** data NeverEmptyList a = NEL a [a] -- (1..Infinity elements)

The package provides all sorts of transformation instances between this
types (except for tuples, 3ples, 4ples... I didn't make all transforms fo
them - only list - (N)ple and opposites)

I tried also to deal with transforms like container a - a, a -
container a using OverlappingInstances. But failed to approve them -
probably due to the lack of experience with this extension. I found them
introducing too much unwanted complexity into the reasoning about types. It
was the last straw to me, when GHC started to proving me, that unity is not
less general then any type variable a, and demanding tribute of
IncoherentInstances.
---

Any feedback is appreciated.

Best regards, Andrey.
-- 
View this message in context: 
http://old.nabble.com/ANNOUNCE%3A-Cardinality-0.1-tp27239964p27239964.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] short licensing question

2010-01-11 Thread Andrey Sisoyev


Svein Ove Aas wrote:
 
 In this case, LGPL is a problem. It requires you to offer a way to
 re-link such binaries against new versions/implementations of the
 library, which in practice requires it to be either open source or
 dynamically linked.
 

Don't understand that. Can't we just put a constraint: our binary works
only with versions x.x.x-y.y.y of this LGPL licensed library? The Cabal
provides a way to put such constraint in build-depends...

Andrey

-- 
View this message in context: 
http://old.nabble.com/short-licensing-question-tp27110059p27114282.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


[Haskell-cafe] HackageDB is not for ... ?

2010-01-04 Thread Andrey Sisoyev

Hello everybody!

I'm planning not a small project, and intuition suggests me, that I should
use heavily the rule separate and rule. So I must separate the project
into many maximum independent and general pieces (packages), make them, and
finally glue it into my project. The pieces and their dependencies will form
an oriented graph without cycles and with overall path finishing into the
final project.
So far so good I have made two pieces: 
** http://hackage.haskell.org/package/PCLT-DB
** http://hackage.haskell.org/package/PriorityChansConverger

But I'm coming to understand, that it's not polite to other community
members to publish just every package my project will consist of, because we
do not want to garbage HackageDB. 
-
Consider cases:
(1)
I don't want to publish package A, because I doubt anyone will find it
useful.
But I develop independent packages B and C, that will be usefull for the
community, and want to publish them on Hackage, but they require package A!

[Solution] Publish package A, but make it maximum general and complete in
itself.

(2) 
I don't want to publish package A, because it's tiny. Well imagine something
same popular and useful, like Ord class. 10 lines of code. But I don't want
to repeat these lines in every other package.

[Solution] Same as for (1) I guess.

(3) 
I don't want to publish package A, because it's about adjacent system.
I'm making 3 packages, that all use DBMS (PostgreSQL). All three are thught
to be independent. But! They all in their DDL scripts use table inheritance
from a common ancestor table nameables, which is everywhere defined the
same:

 CREATE TABLE nameables ( -- an ancestor table
  namevarchar NOT NULL DEFAULT 'name not given'
, description varchar NULL 
, comments  varchar NULL
 ) TABLESPACE tabsp_pcltcatalogs;
 GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE nameables TO
 user_someCurrentSchema_data_admin;
 GRANT SELECT ON TABLE nameables TO user_someCurrentSchema_data_reader;

Now what do I do with that??  
The problem gets even more complicated be the fact, that dependent packages
may use different DB schemes, so DDL sql script from Nameables will have to
be run additionally for them. But that's easy to solve - just decide,
whether to add or not by build-depends a comment -- with DDL init, and
maybe additional instruction in README.

[Solution] ???
[Solution A] Well, of course, I can pretend that this package may be is
Haskellish enough, by inventing something which I don't really need:

 data Name = Name { nName :: String, nDescription :: Maybe String,
 nComments :: Maybe String }

 class Nameables a where
 getName :: a - Name
 
 class HasPrimaryKey a = NameableInDBOnly a where
 getNameFromDB :: Connection - a - IO Name

This + sql script and instruction, how to initialize DB. Is it okay to
publish this? Looks like garbage...

[Solution B] Do my own version control and add same pieces to every package
that use Nameable. Don't like this solution. May be I should start using
other repository systems like github or darcs, and then this solution will
seem more natural to me?.. 
-- 
These are my thoughts on the theme. In any case I come to wanting to publish
the packages anyway. Probably I miss something in ideology and methodology
of using Hackage as community repository.

And what do you think about it?

Regards,
Andrey 
-- 
View this message in context: 
http://old.nabble.com/HackageDB-is-not-for-...---tp27022312p27022312.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] HackageDB is not for ... ?

2010-01-04 Thread Andrey Sisoyev

 Find other package and send a patch (like category-extras) if it
 applies?

That is good, if I find other package, that satisfies my requirements (or
does, with my patch). But that's a solution for a different case. Consider
(1) and (2) to be conceptually unique.

 [Solution C] Create package. Don't publish it but install locally.

That's what I meant by [Solution B]. 
Let's name this package A. The problem arises when I want to publish
something, that depends on A. 
And if I publish 3 such packages, that depend on A? Then I have to merge A
with all three. I also have to do my own versions control, because some may
requier newer A, some - older A. That's a lot of manual administration.

Andrey
-- 
View this message in context: 
http://old.nabble.com/HackageDB-is-not-for-...---tp27022312p27023914.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] ANNOUNCE: PriorityChansConverger-0.1

2010-01-03 Thread Andrey Sisoyev

 thanks, it will be useful.
That's pleasant to hear, Bulat. =)

 whether it works in IO or STM monad?
I made both versions.
PriorityChansConvergerSTM is made in STM in one module. And in another
module STM version is wrapped into IO. The IO version is a buildup on top of
STM version, and it has additional properties:
(1) It (PCC in IO monad) uses MVar locks to secure system from waste work.
I thought, that transactions don't look too lightweight, so few bottleneck
would be great... The negative side of this, is that asynchronous exception
may cause loss of locks. Probably in a future version I will try to
introduce more advanced locking mechanics, which will be secure facing
async-excpts...
(2) STM version has interruptableRead and interruptableWrite operations,
whose interruption is controlled with parameter (STM Bool). IO version also
has these operations + interruptables, that are controlled by parameter
(Chan a, a - Bool). I'm no sure if interruptables for IO monad are made
optimal - they do spawn additional temporary threads, but I didn't see any
better way to make this interruption.

Regards,
Andrey
-- 
View this message in context: 
http://old.nabble.com/ANNOUNCE%3A-PriorityChansConverger-0.1-tp26999572p27002956.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


[Haskell-cafe] ANNOUNCE: PriorityChansConverger-0.1

2010-01-02 Thread Andrey Sisoyev

Hello, cafe!

Didn't find it in HackageDB, so made it.
http://hackage.haskell.org/package/PriorityChansConverger
Category: concurency

Converges multiple channels into one. When user reads from the PCC, the
choice is made - from which channel to read. System selects a nonempty
channel, whose (CurrentPriority, StartPriority) tuple is max. The side
effect of the channel selection is it's CurrentPriority decrease by one, if
it's value becomes less than one, then the CurrentPriority is set to
StartPriority.

Based on STM.TChan, extended with capacity control. Version wrapped into is
also available.
The realization probably isn't very fast and isn't good at memory economy,
since it uses fresh high level primitive - STM. It wasn't intended to be
used with millions of channels. But it's max throughput comparing to the
ordinary Chan throughput is to be estimated (will do it in some future
version).

Regards,
Andrey Sisoyev
-- 
View this message in context: 
http://old.nabble.com/ANNOUNCE%3A-PriorityChansConverger-0.1-tp26999572p26999572.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] Does the TMVar and TChan really obey STM rules?

2009-12-26 Thread Andrey Sisoyev

Thank you, Svein Ove Aas and Neil Brown, for your replies !
I really should have checked the stm sources before panicking here! =)

Regards,
Andrey
-- 
View this message in context: 
http://old.nabble.com/Does-the-TMVar-and-TChan-really-obey-STM-rules--tp26914707p26927805.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


[Haskell-cafe] Does the TMVar and TChan really obey STM rules?

2009-12-24 Thread Andrey Sisoyev

Hi everyone,

isEmptyTMVar :: TMVar a - STM BoolSource

Check whether a given TMVar is empty.

Notice that the boolean value returned is just a snapshot 
of the state of the TMVar. By the time you get to react on its result, 
the TMVar may have been filled (or emptied) - so be extremely careful 
when using this operation. Use tryTakeTMVar instead if possible.

When I read this in the haddock to Control.Concurrent.STM.TMVar, I started
to suspect that the behavior of TMVar and TChan might be worse than I
imagined. 

Few questions on TMVar and TChan:
(1) If 2 threads are sleeping-waiting for the output of TChan, and it gets
filled, do they both wakeup, or just one? 
(2) Similar question about reading/writing TMVar.
(3) If a thread is sleeping-waiting for the output of TChan, but transaction
wants to restart due to the change in any of touched TVar, then does the
thread wakeup and restart the transaction?
(4) Similar question about TMVar.

Also, if there is some paper on this, please, give me a link on it.

Please help,
Andrey
-- 
View this message in context: 
http://old.nabble.com/Does-the-TMVar-and-TChan-really-obey-STM-rules--tp26914707p26914707.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] ANNOUNCE: repr-0.3.2

2009-12-23 Thread Andrey Sisoyev

Where do you make use of it? :)

Andrey
-- 
View this message in context: 
http://old.nabble.com/ANNOUNCE%3A-repr-0.3.2-tp26908749p26909005.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] Are functional dependencies around to stay?

2009-12-22 Thread Andrey Sisoyev

The referenced writings are a bit old. I wonder, what are the current plans
and decisions (or at least dominating opinions) on FD and TF. And when the
equality constraint will be ready.

Andrey


Stephen Tetley-2 wrote:
 
 2009/12/22 Eduard Sergeev eduard.serg...@gmail.com:
 
 As was previously noted they are supposed to be replaced by type
 families,
 
 Hi Eduard
 
 Currently this seems a more like a rumour than a fact - from [1] Type
 Families and Fun Deps are equivalently expressive which seems a
 worthwhile point to restate. From [2] the Haskell prime committee want
 one or the other but not both, and will resolve matters sometime in
 the future.
 
 Best wishes
 
 Stephen
 
 [1]
 http://www.haskell.org/pipermail/haskell-cafe/2009-February/055890.html
 [2] http://www.haskell.org/pipermail/haskell-prime/2008-April/002434.html
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 

-- 
View this message in context: 
http://old.nabble.com/Are-functional-dependencies-around-to-stay--tp26873777p26895997.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


Re: [Haskell-cafe] Are functional dependencies around to stay?

2009-12-21 Thread Andrey Sisoyev

I believe, whenever this http://hackage.haskell.org/trac/ghc/ticket/2715
ticket is closed (with completition), we get a more general substitution to
Functional Dependencies. I hope it happens really soon, because I need it
already. =) 
So it's worth to prepare yourself better to Type Families.

As for deriving of fundeps, outside of Haskell I saw them already used in
methods used in a base of reasoning about RDB (relational data bases)
structures. For more on that search web by keywords normalization rules
functional dependencies, that's an interesting subject if you possess it in
practice.

Regards,
Andrey


Günther Schmidt wrote:
 
 I'm wondering if there is any chance that functional dependencies will 
 not be around in the future. I do not actually understand the subject 
 yet as such, but I'd like to make sure before I get deeper into it that 
 it's something that will be around in the time to come.
 
 What I understand of Haskell is that it's not so much engineered like 
 other languages but more derived from Math, well the very foundations 
 anyway. But some things I can not determine whether or not they are 
 derived from math and thus will stay, or are engineered and might go 
 away, functional dependencies for instance.
 

-- 
View this message in context: 
http://old.nabble.com/Are-functional-dependencies-around-to-stay--tp26873777p26876746.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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


[Haskell-cafe] ANNOUNCE: PCLT-0.1 and PCLT-DB-0.1

2009-12-11 Thread Andrey Sisoyev

Hello, cafe!

It's an honor for me to announce my first two packages, I developed in
Haskell:
** http://hackage.haskell.org/package/PCLT
** http://hackage.haskell.org/package/PCLT-DB

PCLT is an abbreviation for Parametric Composable Localizable Templates
- in fact it should also hold Detalizable. Term Detailizable content
(message) in this package has a following meaning: some content,
representing which it is possible to regulate, in how much details it is
represented.
Localizable means localizable in languages, which is a message is
available in multiple languages.
Composable - it is possible to compose multiple templates into one.

Conceptually, this package is a powerful extension to the well known Show
class. Whenever you feel, that common Show is not enough for your needs,
please consider using my PCLT. The extension is thought to be embedded in
any Haskell program, which requires multilingual support, and/or where
messages should be detailizable.

PCLT-DB is an addon to PCLT, which enhances catalog with PostgreSQL powers.
ER diagram:
http://i1.fastpic.ru/big/2009/1212/f0/5b9845716e5a6984e9bc9d62a61928f0.png

Both packages are well documented, has Hello World examples, and are
selfexamples - the PCLT errors representations are available in two
languages: English and Russian. Used license: LGPL.

Regards,
Andrey Sisoyev
-- 
View this message in context: 
http://old.nabble.com/ANNOUNCE%3A-PCLT-0.1-and-PCLT-DB-0.1-tp26754004p26754004.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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