shefy gur ary - Page 2 - Developer IT

no pg_hba.conf entry for host

- by Priya

Hi All I am new to Perl as well as Postgresql I get following error when i try to connect using DBI DBI connect('database=chaosLRdb;host=192.168.0.1;port=5433','postgres',...) failed: FATAL: no pg_hba.conf entry for host "192.168.0.1", user "postgres", database "chaosLRdb", SSL off Here is my pg_hba.conf file: # "local" is for Unix domain socket connections only local all all md5 # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 host all postgres 127.0.0.1/32 trust host all postgres 192.168.0.1/32 trust host all all 192.168.0.1/32 trust host all all 192.168.0.1/128 trust host all all 192.168.0.1/32 md5 host chaosLRdb postgres 192.168.0.1/32 md5 local all all 192.168.0.1/32 trust My perl code is #!/usr/bin/perl-w use DBI; use FileHandle; print "Start connecting to the DB...\n"; @ary = DBI->available_drivers(true); %drivers = DBI->installed_drivers(); my $dbh = DBI->connect("DBI:PgPP:database=chaosLRdb;host=192.168.0.1;port=5433", "postgres", "chaos123"); May I know what i miss here?

Read the article

How to functionally generate a tree breadth-first. (With Haskell)

- by Dennetik

Say I have the following Haskell tree type, where "State" is a simple wrapper: data Tree a = Branch (State a) [Tree a] | Leaf (State a) deriving (Eq, Show) I also have a function "expand :: Tree a - Tree a" which takes a leaf node, and expands it into a branch, or takes a branch and returns it unaltered. This tree type represents an N-ary search-tree. Searching depth-first is a waste, as the search-space is obviously infinite, as I can easily keep on expanding the search-space with the use of expand on all the tree's leaf nodes, and the chances of accidentally missing the goal-state is huge... thus the only solution is a breadth-first search, implemented pretty decent over here, which will find the solution if it's there. What I want to generate, though, is the tree traversed up to finding the solution. This is a problem because I only know how to do this depth-first, which could be done by simply called the "expand" function again and again upon the first child node... until a goal-state is found. (This would really not generate anything other then a really uncomfortable list.) Could anyone give me any hints on how to do this (or an entire algorithm), or a verdict on whether or not it's possible with a decent complexity? (Or any sources on this, because I found rather few.)

Read the article

Javascript Graph Layout Engine

- by GJK

I'm looking for a Javascript library/engine that can do graph layouts. (And when I say layouts, I mean logically position vertices nicely.) The graphs I'm working with are all m-ary trees. M is usually no more than 5 or 6, but it can be greater in some cases. I do have something that I use now, Graphviz's node program, and it works perfectly. The problem is, when running a web app, I have to send a request to the server every time I want a layout. Preferably, I would like something written in Javascript that can be quickly run on the client side. All it needs to do is provide layout information (relative positioning and whatnot). I don't need it to draw to a canvas or use SVG or anything, all I'm interested in is the layout. Library use like jQuery or RaphaelJS is fine by me. I'll work with it. I'm just looking for something to speed things along a little. Also, I'd consider writing my own if I could find a nice description of an algorithm to do the layouts. But I really don't want to spend too much time. I have something that works now, so getting it on the client side is just a bonus, not a necessity.

Read the article

Are free operator->* overloads evil?

- by Potatoswatter

I was perusing section 13.5 after refuting the notion that built-in operators do not participate in overload resolution, and noticed that there is no section on operator->*. It is just a generic binary operator. Its brethren, operator->, operator*, and operator[], are all required to be non-static member functions. This precludes definition of a free function overload to an operator commonly used to obtain a reference from an object. But the uncommon operator->* is left out. In particular, operator[] has many similarities. It is binary (they missed a golden opportunity to make it n-ary), and it accepts some kind of container on the left and some kind of locator on the right. Its special-rules section, 13.5.5, doesn't seem to have any actual effect except to outlaw free functions. (And that restriction even precludes support for commutativity!) So, for example, this is perfectly legal (in C++0x, remove obvious stuff to translate to C++03): #include <utility> #include <iostream> #include <type_traits> using namespace std; template< class F, class S > typename common_type< F,S >::type operator->*( pair<F,S> const &l, bool r ) { return r? l.second : l.first; } template< class T > T & operator->*( pair<T,T> &l, bool r ) { return r? l.second : l.first; } template< class T > T & operator->*( bool l, pair<T,T> &r ) { return l? r.second : r.first; } int main() { auto x = make_pair( 1, 2.3 ); cerr << x->*false << " " << x->*4 << endl; auto y = make_pair( 5, 6 ); y->*(0) = 7; y->*0->*y = 8; // evaluates to 7->*y = y.second cerr << y.first << " " << y.second << endl; } I can certainly imagine myself giving into temp[la]tation. For example, scaled indexes for vector: v->*matrix_width[2][5] = x; Did the standards committee forget to prevent this, was it considered too ugly to bother, or are there real-world use cases?

Read the article

Are there supposed to be more restrictions on operator->* overloads?

- by Potatoswatter

I was perusing section 13.5 after refuting the notion that built-in operators do not participate in overload resolution, and noticed that there is no section on operator->*. It is just a generic binary operator. Its brethren, operator->, operator*, and operator[], are all required to be non-static member functions. This precludes definition of a free function overload to an operator commonly used to obtain a reference from an object. But the uncommon operator->* is left out. In particular, operator[] has many similarities. It is binary (they missed a golden opportunity to make it n-ary), and it accepts some kind of container on the left and some kind of locator on the right. Its special-rules section, 13.5.5, doesn't seem to have any actual effect except to outlaw free functions. (And that restriction even precludes support for commutativity!) So, for example, this is perfectly legal (in C++0x, remove obvious stuff to translate to C++03): #include <utility> #include <iostream> #include <type_traits> using namespace std; template< class F, class S > typename common_type< F,S >::type operator->*( pair<F,S> const &l, bool r ) { return r? l.second : l.first; } template< class T > T & operator->*( pair<T,T> &l, bool r ) { return r? l.second : l.first; } template< class T > T & operator->*( bool l, pair<T,T> &r ) { return l? r.second : r.first; } int main() { auto x = make_pair( 1, 2.3 ); cerr << x->*false << " " << x->*4 << endl; auto y = make_pair( 5, 6 ); y->*(0) = 7; y->*0->*y = 8; // evaluates to 7->*y = y.second cerr << y.first << " " << y.second << endl; } I can certainly imagine myself giving into temp[la]tation. For example, scaled indexes for vector: v->*matrix_width[5] = x; Did the standards committee forget to prevent this, was it considered too ugly to bother, or are there real-world use cases?

Read the article

Implementation question involving implementing an interface

- by Vivin Paliath

I'm writing a set of collection classes for different types of Trees. I'm doing this as a learning exercise and I'm also hoping it turns out to be something useful. I really want to do this the right way and so I've been reading Effective Java and I've also been looking at the way Joshua Bloch implemented the collection classes by looking at the source. I seem to have a fair idea of what is being done, but I still have a few things to sort out. I have a Node<T> interface and an AbstractNode<T> class that implements the Node interface. I then created a GenericNode<T> (a node that can have 0 to n children, and that is part of an n-ary tree) class that extends AbstractNode<T> and implements Node<T>. This part was easy. Next, I created a Tree<T> interface and an AbstractTree<T> class that implements the Tree<T> interface. After that, I started writing a GenericTree<T> class that extends AbstractTree<T> and implements Tree<T>. This is where I started having problems. As far as the design is concerned, a GenericTree<T> can only consist of nodes of type GenericTreeNode<T>. This includes the root. In my Tree<T> interface I have: public interface Tree<T> { void setRoot(Node<T> root); Node<T> getRoot(); List<Node<T>> postOrder(); ... rest omitted ... } And, AbstractTree<T> implements this interface: public abstract class AbstractTree<T> implements Tree<T> { protected Node<T> root; protected AbstractTree() { } protected AbstractTree(Node<T> root) { this.root = root; } public void setRoot(Node<T> root) { this.root = root; } public Node<T> getRoot() { return this.root; } ... rest omitted ... } In GenericTree<T>, I can have: public GenericTree(Node<T> root) { super(root); } But what this means is that you can create a generic tree using any subtype of Node<T>. You can also set the root of a tree to any subtype of Node<T>. I want to be able to restrict the type of the node to the type of the tree that it can represent. To fix this, I can do this: public GenericTree(GenericNode<T> root) { super(root); } However, setRoot still accepts a parameter of type Node<T>. Which means a user can still create a tree with the wrong type of root node. How do I enforce this constraint? The only way I can think of doing is either: Do an instanceof which limits the check to runtime. I'm not a huge fan of this. Remove setRoot from the interface and have the base class implement this method. This means that it is not part of the contract and anyone who wants to make a new type of tree needs to remember to implement this method. Is there a better way? The second question I have concerns the return type of postOrder which is List<Node<T>>. This means that if a user is operating on a GenericTree<T> object and calls postOrder, he or she receives a list that consists of Node<T> objects. This means when iterating through (using a foreach construct) they would have perform an explicit cast to GenericNode<T> if they want to use methods that are only defined in that class. I don't like having to place this burden on the user. What are my options in this case? I can only think of removing the method from the interface and have the subclass implement this method making sure that it returns a list of appropriate subtype of Node<T>. However, this once again removes it from the contract and it's anyone who wants to create a new type of tree has to remember to implement this method. Is there a better way?

Developer IT