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

Re: [Pharo-project] Issue 3472 in pharo: Text selection problem in Pharo-dev 1.2

by pharo＠googlecode.com

Updates: Cc: stephane.ducasse Comment #6 on issue 3472 by laurent.laffont: Text selection problem in Pharo-dev 1.2 http://code.google.com/p/pharo/issues/detail?id=3472 Issue 3453 has been merged into this issue.

Dec. 22, 2010

Re: [Pharo-project] PharoCore #12884

by Sven Van Caekenberghe

On 22 Dec 2010, at 10:58, StÃ©phane Ducasse wrote: >> Hi, >> >> I just updated my 1.2 core to #12884 with 3 updates and my MC repos are gone from my packages, only the standard repos remain. >> >> Maybe this is a sign of something that went wrong. > > no this is just that some package where home-orphaned and marcus issued a command to > clean (because you can have duplicate repo with the same name but different password -- > a hell) > and reassign all the package repo to package. So your packages got flushed too apparently. > Sorry. > > Stef >> >> Sven No problem, if this is expected/normal than it is OK for me, Thx, Sven

Dec. 22, 2010

Re: [Pharo-project] Issue 3453 in pharo: Primitive failed on ByteString>>copyFrom:To:

by pharo＠googlecode.com

Updates: Status: Duplicate Cc: -stephane.ducasse Mergedinto: 3472 Comment #2 on issue 3453 by laurent.laffont: Primitive failed on ByteString>>copyFrom:To: http://code.google.com/p/pharo/issues/detail?id=3453 duplicate of #3472

Dec. 22, 2010

[Pharo-project] Issue 3475 in pharo: Finder insensitive selector/class researches

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3475 by Benjamin.VanRyseghem.Pharo: Finder insensitive selector/class researches http://code.google.com/p/pharo/issues/detail?id=3475 Now, the selector and class researches in Finder are case insensitive. Posted in PharoTaskForces and PharoInbox

Dec. 22, 2010

Re: [Pharo-project] Issue 2232 in pharo: digitValue speed up part one and two.

by pharo＠googlecode.com

Comment #9 on issue 2232 by stephane.ducasse: digitValue speed up part one and two. http://code.google.com/p/pharo/issues/detail?id=2232 I'm now checking normally just the last method definition but I'm taking the time to look.

Dec. 22, 2010

Re: [Pharo-project] Dear Santa ...

by Janko MivÅ¡ek

Hi Eliot, On 20. 12. 2010 20:00, Eliot Miranda wrote: > - Namespaces > - Breakpoints > - Monticello/Metacello directly from browser > - portable async FFI > - SOAP/WSDL with object mapping and one-click tool > - even more usability enhancements > - rock solid image and VM for image-only persistency > - more Eliot :) > > > :) But this could mean lots of things. a) I'm not doing enough, b) I > need to put on weight, c) my jokes are great, d) you want specific > things done in the VM area. So while this made me laugh and so far is > inspiring (I mean, if you really do mean a) I'm going to have a > miserable xmas, and my wife is going to be miserable if you mean b) ) > I'd love for you to make some specific suggestions as to what more Eliot > might mean (besides eating a /lot/ over xmas to try and create a few > more kilos of Eliot). :) Being a bit short on time to pair your humoresque style :), let me jump strait into what "more Eliot" means to me: - sooner a really good open-source Smalltalk VM on pair and extending VW one. That is, more opportunity to you to get your ideas how should a VM look like to fly towards a goal, - immutability/read only objects or some other mechanism to detect object's change easily, - rock solid, stable and reliable VM and image for us the "image as a database" guys, who are more numerous as one wants to confess :) Again, VW is such an example, very reliable for such persistency, for which you deserves quite some gratitude :) Well, let me finish, otherwise you'll start right now. But I don't understand: if you start right now, you won't have a time to get fat, if you don't start now, you',ll get fat from all those Christmas food. Your wife is going to be miserable in any case...:) Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 22, 2010

Re: [Pharo-project] about copy in the bug tracker

by Mariano Martinez Peck

On Wed, Dec 22, 2010 at 11:06 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > am i the only one having problem with copy (control-C when on the bug > tracker)? > I hate when it create a new entry. > no, you are not alone. It happens the same to me. Maybe it is only mac? > > Stef > > > >

Dec. 22, 2010

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

by Tudor Girba

Like I wrote before, MooseAlgos is a separate and independent project. But, yes, it would be really great to have a stronger effort around these topics, and the Moose community could provide the right environment for this. Cheers, Doru On 22 Dec 2010, at 08:50, StÃ©phane Ducasse wrote: > 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. >> > > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Dec. 22, 2010

Re: [Pharo-project] Issue 3459 in pharo: includesSubstring: aString caseSensitive: caseSensitive / includesSubString:

by pharo＠googlecode.com

Comment #3 on issue 3459 by Benjamin.VanRyseghem.Pharo: includesSubstring: aString caseSensitive: caseSensitive / includesSubString: http://code.google.com/p/pharo/issues/detail?id=3459 I do not want to have one method, but that both selector started the same way one started by includesSubstring: and the other by includesSubString: ^ I think one of this selector should be changed ^^ PS : I hate too the shortcut on CMD+C to create a new entry !!!!!!!!

Dec. 22, 2010

Re: [Pharo-project] big ui decisions

by Igor Stasenko

On 22 December 2010 11:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 22, 2010, at 10:46 AM, Chip Nowacek wrote: > >> >> Thanks for your help so far. >> >> Now that I've had a chance to get my feet wet, start an eval of VW, watch >> Peter Fisk's progress, etc. I've hit a scary point. To go the distance, my >> app needs the maturity and capacity of Squeak/Pharo/VW(?). And, near- and >> long-term, it needs an elegant, cogent, captivating, intelligent, engaging, >> interactive front end. I've considered doing it in Flash or Silverlight or >> AIR (fat client) or straight JavaScript - though splitting the tiers and >> forgetting the backend seems like a lot of deferred pain. I know I have to >> worry about deployment. I am. I'd rather do it through the browser. And, >> even though DabbleDB and others are some of the coolest apps ever, I don't >> see Seaside cutting the front-end mustard (at least the way I understand >> things at this point). > > what is specific about your app? > >> I sure wish there was a lightening-fast, >> browser-based, morphic-3-supporting VM so I could run ST on both tiers. A >> sexy, Smalltalk Lively-Kernel. I'm still trying to get Clamato to work. >> >> So, in your professional, experienced opinions, can I get a front end on >> Pharo (either in-image via Rome/Athens or some cooler-than-I've-seen, >> through-the-browser front end)? > > it depends what you need. > Our plans with igor are to produce a nice API to access Cairo and openVG but this will not happen before 3-4 months. > yes, don't leave from the radar, because eventually i want to make modern, nice & sexy UI, using vector-graphics engine backend. Sure thing, if you wanna help in this regard - you're welcome, because this field is VAST and there is enough work for 10 people, not just me alone. :) >> With all due respect to the Founding >> Fathers, I can't do eToys. Should I just do the whole client tier in in JS >> for the prototype and then hook to Seaside later? > > did you see nextPlan? > Because they generate svg too? > >> >> Any thoughts would be deeply appreciated. >> >> Thanks, >> >> Chip >> -- >> View this message in context: http://forum.world.st/big-ui-decisions-tp3160359p3160359.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 22, 2010