Indeed. Mondrian works relative well for displaying and layout graph below 20.000 nodes. Over that, an external library is best. There is a bridge Mondrian<--> graphviz.
Cheers, Alexandre On 18 Dec 2010, at 11:26, Levente Uzonyi wrote: > On Sat, 18 Dec 2010, Stéphane Ducasse wrote: > >> May this is a ridiculuous thought but may be it would be good to start an >> effort on >> build a library for Smalltalk. Reusing some part of mondrian could be good. > > It would be very slow and really a lot of work. Mondrian is nice for > visualization, but a Graph library is a lot more than that. > > > Levente > >> >> Stef >> >> >>> JGraphT worked alright in what I tried against in the past, but it won't >>> scale to huge heights like most libs without major tweaking or a graph DB >>> backing it along with some serious threading. >>> >>> Just to throw in a few others I've used, but not with Smalltalk: >>> >>> * https://software.sandia.gov/trac/mtgl MTGL >>> * http://lemon.cs.elte.hu/trac/lemon LEMON >>> * .NET http://quickgraph.codeplex.com/ Quickgraph /Graph# >>> * http://igraph.sourceforge.net/introduction.html iGraph >>> * http://snap-graph.sourceforge.net/ SNAP >>> >>> Of the above, I've had some of the best experience with LEMON in terms of >>> scale and speed for real-world usage. Unfortunately, none of these libraries >>> include everything you'd want, so at some point you will have to roll some >>> stuff yourself. That's been my experience at least. >>> >>> Some Graph or Graph-like Databases (tend to have some algorithm libs as >>> well): >>> >>> * http://www.infinitegraph.com InfiniteGraph (this runs on Objectivity >>> underneath the covers which has a Smalltalk impl) >>> * http://www.neo4j.org neo4j >>> * http://www.kobrix.com/hgdb.jsp HyperGraphDB >>> >>> Some related useful items for dealing with large sets and graphs when you >>> are thinking about performance and/or parallel processing: >>> >>> * http://gauss.cs.ucsb.edu/~aydin/doc/html/index.html Combinatorial BLAS >>> * http://www.semanticdesigns.com/Products/PARLANSE/ PARLANSE >>> * http://research.microsoft.com/en-us/projects/dryadlinq/ DRYAD LINQ >>> >>> FYI, I would strongly recommend against using Ruby for anything with graphs >>> except as a simple client lib. I spent a lot of time on this before and it >>> simply does not scale or perform to anything beyond very simple cases, and >>> the memory footprint in a real app becomes horrendous. We had to tweak the >>> hell out of some libs to get anything decent and even then we ended up >>> writing stacks of C to compensate. If you're just dealing with 100 vertex >>> undirected graphs, then it works great. It's honestly the fault of a lot of >>> the libs rather than the language, but nonetheless be warned. >>> -- >>> View this message in context: >>> http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747p3092943.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
