December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3474 in pharo: BmpReadWriterPlugin primitives should be used

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de Labels: Type-Squeak New issue 3474 by Torsten....(a)astares.de: BmpReadWriterPlugin primitives should be used http://code.google.com/p/pharo/issues/detail?id=3474 Andreas wrote: "For some strange reasons the BMP read/write primitives weren't enabled. Probably an oversight on my behalf. The primitives improve performance by 10-20x" Code: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156042… Test adoption: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156043… Discussion: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-December/006199.html

Dec. 22, 2010

Re: [Pharo-project] [TODO] 1.2 Core + Full

by StÃ©phane Ducasse

Yes I will help too. On Dec 22, 2010, at 8:07 AM, Marcus Denker wrote: > For 1.2 to to be released, we need to > > a) get all tests green. > There are right now 9 failing tests in Core and 9 additional one in the full image. > > 9 of 7915 tests fail: > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… > > 18 of 10284 tests fail: > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… > > some of those are test-server artefacts that only fail on the testserver. > > b) Bug Tracker. Here the issues need to be either resolved or decided to be not show-stoppers > (there will be a 1.3 release! So somehting that is already not in 1.1, why do we need in in 1.2? > A release is just a usable snapshot of an on-going process) > > 23 reports are tagged as 1.2: > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2&colspec=ID… > > 8 reports are tagged as 1.2 for the full image? > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage&c… > > All failing tests do have bug-tracker entries. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Dec. 22, 2010

Re: [Pharo-project] [TODO] 1.2 Core + Full

by Luc Fabresse

Hi Marcus, Thanks, your mails are good to push me ahead ;-) I think that #3455 is ready for integration (make 2 tests pass in dev). and #3447 too (provided CS or just remove the method). #Luc 2010/12/22 Marcus Denker <marcus.denker(a)inria.fr> > For 1.2 to to be released, we need to > > a) get all tests green. > There are right now 9 failing tests in Core and 9 additional one in the > full image. > > 9 of 7915 tests fail: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… > > 18 of 10284 tests fail: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… > > some of those are test-server artefacts that only fail on the testserver. > > b) Bug Tracker. Here the issues need to be either resolved or decided to be > not show-stoppers > (there will be a 1.3 release! So somehting that is already not in 1.1, > why do we need in in 1.2? > A release is just a usable snapshot of an on-going process) > > 23 reports are tagged as 1.2: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2&colspec=ID… > > 8 reports are tagged as 1.2 for the full image? > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage&c… > > All failing tests do have bug-tracker entries. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Dec. 22, 2010

[Pharo-project] accessors vs direct access in Cog

by StÃ©phane Ducasse

Hi guys Ideally I would love to be able to use accessors as the abstraction layer that they can bring us: I mean the fact that we could avoid to have offset based bytecode means that we could reuse a lot more the methods (in special case - mixins and others). Now I have a question does the JIT or the shortcut (not sure if this is in stackVM) blurry the cost of accessors vs. direct accesses? Does anybody run a benchmarck about self x vs x in Cog recently on a real app? Stef

Dec. 22, 2010

Re: [Pharo-project] [squeak-dev] Re: Graph library in Smalltalk - Need for advices

by StÃ©phane Ducasse

this is a nice analysis. Now I think that if different lib are needed for people then starting to build some of them is important. I know that Jannik also implemented and optimize tarjan and other graph algorithms for moose so cedric it would be probably a good start to check that and probably to make the moose graph algo lib a separate entity. We (the moose people) also need a good graph lib. Stef > 1. Scalability > 2. Data structures > 3. Algorithms > 4. Performance > 5. Visualization > > I think you need to at least consider all the above when creating a library. > In fact, you probably should break it up as many libraries do into several > components: > > 1. Common, useful data structures (Vertex, Edge, Adjacency List, Adjaceny > Matrix, etc.) that are optimized for your language - hopefully smalltalk > > 2. Computations / Measurements > > 3. Algorithms - layout, common graph problems, etc. > > 4. Persistence - database or otherwise, likely several supporting libs > specific to the persistence mechanism or implementing some kind of pattern > to be agnostic. The data structures should at least be designed in such a > way that they are persistence friendly to put in something like Gemstone, > Magma, Image, etc. See for example InfiniteGraph which has a Java interface > built on Objectivity. > > 5. Visualization - desktop, web, and static output. > > The problem here is that creating a graph library is a huge undertaking. It > might not sound like it, but they can grow to epic proportions. From my > comments, you can see that it is really not the fault of any particular lib, > but rather the subject matter. You could spend a lifetime packing in > features. The real key is just to create a series of libs that work well > together and not constantly reinvent the wheel with node classes in each > library. > > A secondary problem is doing graph analysis and even drawing graphs can take > a lot of horse power. Parallelism is a tough issue with graph libraries and > there's a multitude of approaches from pure threads to map/reduce to random > walking and stream processing. This is further compounded by persistence > where you need to start doing things like graph healing, partitioning, and > sharding to scale to massive levels and maintain performance. > > I just want to mention to others that graphs are hugely useful in general to > solve a variety of problems from recommendations to meta programming. It's > not just pretty pictures and experiments with molecules. There's a lot of > potential in Smalltalk to do something since generally I feel Smalltalkers > aren't bound by or afraid of new approaches to old problems. Graph databases > in many cases could replace relational DBs for example and let your app do > all kinds of stuff you might never have thought of otherwise. > > I could go on and on, but I'll stop myself here. Comments or thoughts? > > > > > > > StÃ©phane Ducasse wrote: >> >>> >>> I've started looking at the exemples YossiDM gave to me and in particular >>> Lemon which was according to him his best experience. I found the model >>> quite clear and covering all what I expect for a generic graph lib >>> (directed, undirected, mapping concept, iterators, and algorithms of >>> course). Moreover and contrary to Boost, it's still developed in 2010. >>> >>> To be more precise, here's what I expect for a generic graph lib in >>> smalltalk (note all in Lemon except visualization): >>> >>> - data structure: directed graphs, undirected graphs, possible loop and >>> parallel edged, ..., trees (?) >>> - mapping: easily map objects, informations on nodes and/or edges (here, >>> don't know if I'd like subclassing nodes/eges instead...) >>> - iterators: efficient way to iterate over nodes and edges >>> - algorithms: basic algorithms implementation (bfs, dfs, ..., shortest >>> paths, ...), and plug-ability for specific ones... >>> - visualization: having an interactive graph visualization web/SVG and >>> eventually morphic (... graphviz, mondrian, .......) >>> >>> then, I could use this for my research work... >>> - I need "belief" nodes with associated conditional beliefs tables >>> - I need to implement algorithms to propagate an information change >>> (change of a node state) in any nodes... >>> ****mainly, I'd like to get junction trees from a graph [1] which are >>> rely useful for several domains in machine learning field *** >>> >>> Actually, I don't know if I really need a graph lib as a simple >>> implementation directed to bayesian should be enough but it's the second >>> time I need graphs (last time was for planification) and I think that >>> would be great to have a nice and clean basic implementation. >>> >>> Couldn't we start developing something similar to Lemon (regarding "API", >>> enitites, etc...) that would work for small scale project project in >>> smalltalk ? >> >> It would be excellent. >> Because now that you have a full time permanent position you can invest a >> bit and in 2 years you can get something really sexy.... >> This is what we are doing all the time around pharo. >> >>> Yossi, what were the limitations you found with Lemon ? >>> >>> Cheers, >>> >>> CÃ©drick >>> >> >> >> >> > > -- > View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 22, 2010

Re: [Pharo-project] [squeak-dev] Re: Graph library in Smalltalk - Need for advices

by StÃ©phane Ducasse

On Dec 22, 2010, at 12:25 AM, YossiDM wrote: > > Sorry for the late reply, I've been away on business. I'm going to have to > make one of those unfortunate long posts, so hopefully I can hold the > attention span of those already interested anyway. > > CÃ©drick - I found the main limitation with Lemon to be that it was a pain to > extend as well as to integrate a nice persistence layer. > > StÃ©phane, regarding Mondrian - I've looked over the code and while it's ok > for what it does, I think everyone would admit it's not designed to be a > real graph library. It does what it needs to do and no more, so I would keep > it that way for now. You really do need to design a good graph lib from the > ground up. yes mondrian is not about a graph lib. It is a tool to draw potentially graphs > > It's been my experience after using probably 20 different graph libraries in > real projects over the years that the following themes reoccur: > > 1. Library is good for visualization, but not for calculations - shortest > path, centrality, MST, etc. > > 2. Library is good for algorithms but has no visualization support > > 3. Graph library relies too much on other libraries that are not that > impressive either. Graphviz comes to mine. Great tool, but frankly the > visualizations looks awful by today's standards and it's harder to do > something fully dynamic. Piping a dot file to a unix process to produce a > static image is not terribly useful in things like web applications. > > 4. Library does not scale predictably or to a certain point. > > 5. Library does not support persistence properly. > > 6. Library forces an API that takes over your data too much or doesn't play > well with existing data. Any model that forces inheritance for Vertex and > Edge classes comes to mind. See neo4j for some examples of a poor API on > this point. > > 7. Library is good all around but lacks depth (missing algorithms, measures, > etc) and does not play well with others. > > 8. Every library has its own idea of what a vertex and edge should be and > there's no good way of passing data between them in a nice manner. > > 9. Visualization libraries have a multitude of issues - specific to desktop > or web only, static output, no capability to annotate vertex or edges, no > pruning... I have yet to find one that is both pretty and useful to this day > without nearly recreating a new library each time. > > The reality is every library will have to make compromises at a minimum in > the following areas: > > 1. Scalability > 2. Data structures > 3. Algorithms > 4. Performance > 5. Visualization > > I think you need to at least consider all the above when creating a library. > In fact, you probably should break it up as many libraries do into several > components: > > 1. Common, useful data structures (Vertex, Edge, Adjacency List, Adjaceny > Matrix, etc.) that are optimized for your language - hopefully smalltalk > > 2. Computations / Measurements > > 3. Algorithms - layout, common graph problems, etc. > > 4. Persistence - database or otherwise, likely several supporting libs > specific to the persistence mechanism or implementing some kind of pattern > to be agnostic. The data structures should at least be designed in such a > way that they are persistence friendly to put in something like Gemstone, > Magma, Image, etc. See for example InfiniteGraph which has a Java interface > built on Objectivity. > > 5. Visualization - desktop, web, and static output. > > The problem here is that creating a graph library is a huge undertaking. It > might not sound like it, but they can grow to epic proportions. From my > comments, you can see that it is really not the fault of any particular lib, > but rather the subject matter. You could spend a lifetime packing in > features. The real key is just to create a series of libs that work well > together and not constantly reinvent the wheel with node classes in each > library. > > A secondary problem is doing graph analysis and even drawing graphs can take > a lot of horse power. Parallelism is a tough issue with graph libraries and > there's a multitude of approaches from pure threads to map/reduce to random > walking and stream processing. This is further compounded by persistence > where you need to start doing things like graph healing, partitioning, and > sharding to scale to massive levels and maintain performance. > > I just want to mention to others that graphs are hugely useful in general to > solve a variety of problems from recommendations to meta programming. It's > not just pretty pictures and experiments with molecules. There's a lot of > potential in Smalltalk to do something since generally I feel Smalltalkers > aren't bound by or afraid of new approaches to old problems. Graph databases > in many cases could replace relational DBs for example and let your app do > all kinds of stuff you might never have thought of otherwise. > > I could go on and on, but I'll stop myself here. Comments or thoughts? > > > > > > > StÃ©phane Ducasse wrote: >> >>> >>> I've started looking at the exemples YossiDM gave to me and in particular >>> Lemon which was according to him his best experience. I found the model >>> quite clear and covering all what I expect for a generic graph lib >>> (directed, undirected, mapping concept, iterators, and algorithms of >>> course). Moreover and contrary to Boost, it's still developed in 2010. >>> >>> To be more precise, here's what I expect for a generic graph lib in >>> smalltalk (note all in Lemon except visualization): >>> >>> - data structure: directed graphs, undirected graphs, possible loop and >>> parallel edged, ..., trees (?) >>> - mapping: easily map objects, informations on nodes and/or edges (here, >>> don't know if I'd like subclassing nodes/eges instead...) >>> - iterators: efficient way to iterate over nodes and edges >>> - algorithms: basic algorithms implementation (bfs, dfs, ..., shortest >>> paths, ...), and plug-ability for specific ones... >>> - visualization: having an interactive graph visualization web/SVG and >>> eventually morphic (... graphviz, mondrian, .......) >>> >>> then, I could use this for my research work... >>> - I need "belief" nodes with associated conditional beliefs tables >>> - I need to implement algorithms to propagate an information change >>> (change of a node state) in any nodes... >>> ****mainly, I'd like to get junction trees from a graph [1] which are >>> rely useful for several domains in machine learning field *** >>> >>> Actually, I don't know if I really need a graph lib as a simple >>> implementation directed to bayesian should be enough but it's the second >>> time I need graphs (last time was for planification) and I think that >>> would be great to have a nice and clean basic implementation. >>> >>> Couldn't we start developing something similar to Lemon (regarding "API", >>> enitites, etc...) that would work for small scale project project in >>> smalltalk ? >> >> It would be excellent. >> Because now that you have a full time permanent position you can invest a >> bit and in 2 years you can get something really sexy.... >> This is what we are doing all the time around pharo. >> >>> Yossi, what were the limitations you found with Lemon ? >>> >>> Cheers, >>> >>> CÃ©drick >>> >> >> >> >> > > -- > View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 22, 2010

[Pharo-project] [TODO] 1.2 Core + Full

by Marcus Denker

For 1.2 to to be released, we need to a) get all tests green. There are right now 9 failing tests in Core and 9 additional one in the full image. 9 of 7915 tests fail: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… 18 of 10284 tests fail: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… some of those are test-server artefacts that only fail on the testserver. b) Bug Tracker. Here the issues need to be either resolved or decided to be not show-stoppers (there will be a 1.3 release! So somehting that is already not in 1.1, why do we need in in 1.2? A release is just a usable snapshot of an on-going process) 23 reports are tagged as 1.2: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2&colspec=ID… 8 reports are tagged as 1.2 for the full image? http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage&c… All failing tests do have bug-tracker entries. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 22, 2010

Re: [Pharo-project] SandstoneDb + SortedCollections

by Ramon Leon

On 12/21/2010 08:51 PM, David Zmick wrote: > What can I do to fix this? Another option might be to use a sort block that isn't a block, but an ordinary object that responds as a sort block would, allowing the collection to be serialized successfully. -- Ramon Leon http://onsmalltalk.com

Dec. 22, 2010

Re: [Pharo-project] SandstoneDb + SortedCollections

by Ramon Leon

On 12/21/2010 08:51 PM, David Zmick wrote: > I am trying to use SandstoneDb to save an Object that contains a > SortedCollection, but it fails with the error: "This message is not > appropriate for this object". Sorted collections contain sort blocks, which aren't serializable with SmartRefStreams, which SandstoneDb is based on. > What can I do to fix this? You can't. What you can do is store an OrderedCollection and sort them on the fly in your accessor method. -- Ramon Leon http://onsmalltalk.com

Dec. 22, 2010

Re: [Pharo-project] Citezen vs. Google Scholar bug??

by csrabak＠bol.com.br

The key seems to have been created "on the fly" as seems to be Author + year + Title formula. I _think_ the real judge has to be BibTeX. I would expect however that this accented character had been type as cou{\"e}t1987effects. By the sabe token, I wonder how it gets rendered in LaTeX the author's name, as it seems the backslash is being 'escaped'. . . -- Cesar Rabak Em 21/12/2010 17:26, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: Stef, I *think* Google Scholar is in the wrong here, but I'll mention it just in case. I've tried to paste the controversial entry below, but in case it gets corrupted in transfer, it is the third hit on Google Scholar with surface tension inclined tube stability Dumitrescu @article{couÃ«t1987effects, title={{The effects of surface tension and tube inclination on a two-dimensional rising bubble}}, author={Cou{\\"e}t, B. and Strumolo, G.S.}, journal={Journal of Fluid Mechanics}, volume={184}, pages={1--14}, issn={0022-1120}, year={1987}, publisher={Cambridge Univ Press} } The BibTeX source above is from GS' "Import into BibTeX" feature. Citezen didn't like it. I am assuming that the problem is that accented e in the key. Changing it to a "plain" e allowed my code to proceed. The real question is whether extended characters are legal in the key? If not, then Citezen is correct to complain. Bill

Dec. 22, 2010