We've refactored the happs repos and are now going to releasing
components of HAppS as individual useful packages. HAppS-Data is the
first one. Don't pull a tag, pull the most recent stuff in the repos.
---
HAppS-Data v0.9: XML, Name/Value Pairs, HList, deriveAll
* toXml and fromXml
order matters. But I hope people are transitioning to using mkCommand
instead of expose as it provides more functionality.
-Alex-
Thomas Hartman wrote:
I have a situation where
... stuff...
$(expose ['setState, 'getState]
f = SetState
compiles but
f = SetState
$(expose ['setState,
There is a simplified version of HList style functionality inside
HAppS-Data because I found Oleg's repo too hard to understand.
-Alex-
Stuart Cook wrote:
On 11/25/07, Thomas Hartman [EMAIL PROTECTED] wrote:
I think I'm running into more or less the same issue discussed at
This sounds like a really interesting piece of software. That being
another significant use for the name Atom these days is as an identifier
for a feed format.
http://en.wikipedia.org/wiki/Atom_(standard)
You may find it easier to advertise and romote this project with a more
unique name.
It might help to point out that its easy to end up with memory/space
leaks in Java/python/ruby/perl too. Also stack overflow is really easy.
Also, you can get into really deep badness if you do anything
interesting with concurrency because of the global interpreter lock etc.
As far as
SearchPath v0.9 does recursive module chasing accross the internet using
a combination of mapfiles you provide and the default map file, caching
the downloaded modules in a local directory. Searchpath can handle
modules in module hierarchies based at a URLs, in tgz archives
accessible via URL,
Searchpath already does recursive module chasing accross the internet.
If your module is available at a url in an unpacked module hierarchy or
in a tgz file or if it is exposed in a darcs/svn/cvs etc repo,
searchpath can retrieve it and put it on your local import path.
The main limitations
I'd really rather factor our the template haskell. It does not leave me
feeling good.
At the specific level, TemplateHaskell doesn't solve the problem of
getting good XML element names. For example with HList lets me annotate
labels with information about whether they are attributes or
Let's be really specific about what we want to have in this regard:
1. repo hosting
2. repo searching
3. A shared/federated name space mapping module names to the URLs of
repos that implement those modules
4. A dev system that uses the name space to download and import chase
the modules
I am playing with using SYB to make generic indexed collections. The
current code is this:
data Syb = Syb [Dynamic] -- list of [Map val (Set a)]
empty item = Syb $ gmapQ (toDyn . emp item) item
where
emp::x-y-Map.Map y (Set.Set x)
emp x y = Map.empty
insert x
The HAppS HTTP code basically delivers the first 64k and a handle to
acquire the rest. The 99% or higher case is that the document fits in
memory so the 64k bound is fine. If you have something bigger, the
user is going to have to decide how to handle that on a case by case basis.
Note:
Actually, standalone deriving doesn't really solve the boilerplate
boilerplate problem. My original complaint here is that I don't want to
explicitly declare a deriving (Data,Typeable) for every type used
somewhere inside a larger type I am using. In this particular case, I
am using SYB to
I'm looking at the XML SYB example
http://www.cs.vu.nl/boilerplate/testsuite/xmlish/Main.hs
I'd like to find a way to pass other type customizations as arguments to
data2content and content2data.
I modified data2Content as follows:
data2content f = element
Claus Reinke wrote:
Actually, standalone deriving doesn't really solve the boilerplate
boilerplate problem. My original complaint here is that I don't want
to explicitly declare a deriving (Data,Typeable) for every type used
somewhere inside a larger type I am using. In this particular case,
I suppose a deriveAll command from template haskell would work. Is that
really possible?
-Alex-
Neil Mitchell wrote:
Hi Alex,
The problem with Data.Derive is that I now have a pre-processor cycle as
part of my build process. Automatic and universal Data and Typeable
instance deriving should
Is there a standard class that looks something like this:
class (Monoid m) = MonoidBreak m where
mbreak::a-m a-(m a,m a)
and it should follow some law like:
m == uncurry mappend $ mbreak x m
-Alex-
___
Haskell-Cafe mailing list
Ok how about this class:
class (Monoid m) = MonoidBreak m where
mbreak::m-m-m
And the condition is
mappend (mbreak y z) y == z
-Alex-
Dan Piponi wrote:
On 6/7/07, Alex Jacobson [EMAIL PROTECTED] wrote:
Is there a standard class that looks something like this:
class (Monoid m
:
On Wednesday 27 June 2007 09:32:16 Alex Jacobson wrote:
Titto,
Have you looked at HAppS.DBMS.IxSet? Right now it provides a generic
way to query indexed sets.
If you want to take a shot at making the queries serializable, I don't
think it would be that difficult (but I have not tried so YMMV
If you create a Data.Map or Data.Set larger than fits in physical
memory, will OS level swapping enable your app to behave reasonably or
will things just die catastrophically as you hit a memory limit?
-Alex-
___
Haskell-Cafe mailing list
Ok, so for low throughput applications, you actually need a disk
strategy. Got it.
Ok, is there a standard interface to BerkleyDB or some other disk based
store?
-Alex-
Duncan Coutts wrote:
On Wed, 2007-08-01 at 11:31 -0700, Bryan O'Sullivan wrote:
Alex Jacobson wrote:
If you create
Will be pushing out the refactored happs repos in the next 2 weeks. The
gist is:
* HAppS.IxSet provides efficient query operations on haskell sets.
* HAppS.State provides ACID, replicated, and soon sharded access to your
application state.
* HAppS.Network will provide server side
- getFieldValue stmt dList
return lst
readTable2 = do
dbh - connect server database user_id passwd
values - retrieveRecords2 dbh
putStrLn $ dLists are : ++ (show values)
br,
Isto
2007/8/1, Alex Jacobson [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED
The challenge was the implement the modcount algorithm not to calculate
primes per se.
(see e.g. http://jjinux.blogspot.com/2005/11/io-comparison.html).
-Alex-
Donald Bruce Stewart wrote:
alex:
This implementation of calculating 1 primes (compiled with GHC -O2)
is 25% slower than the
Thought perhaps the problem is that modcount is just a slower algorithm.
... nevermind. Thanks.
-Alex-
Alex Jacobson wrote:
The challenge was the implement the modcount algorithm not to calculate
primes per se.
(see e.g. http://jjinux.blogspot.com/2005/11/io-comparison.html).
-Alex
Paulo Tanimoto wrote:
The challenge was the implement the modcount algorithm not to calculate
primes per se.
(see e.g. http://jjinux.blogspot.com/2005/11/io-comparison.html).
Can you show us the Python code?
Note this is python for the naive, accumulate and do modulus version.
Not for
The SYB papers provide really powerful functions for accessing and
manipulating a values in arbitrary shaped containers.
The cost of this capability appears to be loss of type checking. For
example gfindtype x returns a maybe y.
Given that the type checker actually has to know whether or
26 matches
Mail list logo
