October 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] Little Meeting at Pittsburg

by Juan Pablo Sandoval Alcocer

I am attending OOPSLA too, It would be a pleasure to be part of the meeting. Juampi 2015-10-25 19:30 GMT-03:00 stepharo <stepharo(a)free.fr>: > Hi > > Guillermo, Andrei, Guido and me are attending OOPSLA so we could have a > small > Pharo meeting. > What about wednesday evening? > > Stef > > -- Saludos, Juan Pablo

Oct. 27, 2015

Re: [Pharo-users] Updated Pharo By Example

by stepharo

Thanks we should really use this. Le 23/10/15 15:19, Stephan Eggermont a Ã©crit : > On 23-10-15 19:15, Thierry Goubier wrote: >> Le 23 oct. 2015 7:00 PM, "Dimitris Chloupis" <kilon.alios(a)gmail.com> a >> Ã©crit : >>> >>> I completely agree with Stef, I did actually removed some >>> screenshots and >> someone put them pack >>> >>> Maybe I can create a pharo script to auto make them for each version >> >> Wasn't there a way to run Smalltalk code inside pillar? Code that would >> open windows, screenshot and return a png. > > Well, there is Documentation-Screenshots in > StephanEggermont/Documentation > > You create a DOScreenshotExporter, set its directory and tell it which > forms/morphs/nautilus/world you want stored there under which filename. > I fixed a few remaining bugs today. > > I presume you should be able to use it in pillar. > > You can use it like > > so := DOScreenshotExporter new. > so directory: FileLocator home. > so writeNautilusMethod: DOScreenshotExporter>>#directory: as: > 'directoryMethod.png' > > It has methods like > DOScreenshotExporter>>writeNautilusMethod: aMethod as: aFileName > self writeBlock: [(Nautilus openOnMethod: aMethod) ui window > imageForm ] as: aFileName > > This makes sure to first rename an existing file before overwriting it. > > DOScreenshotExporter>>writeBlock: aBlock as: aFileName > |temp| > (directory / aFileName) exists ifTrue: [ > temp := (directory / aFileName) renameTo: (aFileName,'tmp') ]. > PNGReadWriter putForm: aBlock value onFileNamed: (directory / > aFileName). > temp ifNotNil: [ temp ensureDelete ] > > Stephan > > >

Oct. 27, 2015

Re: [Pharo-users] Pharo family update

by Adam

Dne Po 26. ÅÃjna 2015 17:26:55, Esteban A. Maringolo napsal(a): > Magritte could be categorized as meta-modelling. OK. > > PostgreSQL, Magma, MongoDB, etc should be Databases. > Persistency should include Voyage, GLORP, SandstoneDB, etc. Sounds good. Still I em wondering about "Server" circle (like I wrote in my other email). Maybe it will be better to merge it with one of siblings. Adam. > Esteban A. Maringolo > > 2015-10-26 17:19 GMT-03:00 stepharo <stepharo(a)free.fr>: > > You can safely remove Marina. > > It is unmaintained, undocumented and not finished. > > > > I did not see Fuel. Could be close to STON > > Would be nice to have parsers > > > > Smacc > > OMeta > > PetitParser > > > > Le 25/10/15 20:23, Adam a Ã©crit : > >> Hello, > >> > >> next update. I tried to follow all sugestions - but not all is > >> implemented > >> into drawings (maybe because I did not quite understand, or I did not > >> found > >> enough information, or something like that). > >> > >> Pharo is mostly development platform, and image shows mostly libraries > >> and > >> frameworks for development, but "Development" circle in the image is more > >> about tools primarly targeted to support process of development. So, if > >> Gofer > >> and Metacello is not used for this purpose (maybe it is, I'm not sure), > >> it > >> should be in "Working" circle. > >> > >> "Working" circle is mostly about tools and applications for "normal" > >> people. > >> Maybe it should be named like: "Desktop"... > >> > >> "Server" circle is meant to show that Pharo itself can offer services to > >> other > >> parties. > >> > >> Development/Working/Server are some kinde of trinity around it everyhing > >> else > >> is rotating. But Pharo is more about Development so other circles are > >> main > >> groups of libraries and frameworks. > >> > >> Adam > >> > >> Dne PÃ¡ 23. ÅÃjna 2015 23:58:48, Adam napsal(a): > >>> Hello, > >>> > >>> I just updated drawing of projects around Pharo. > >>> > >>> Main idea is to guide people (new users of Pharo) through fields of > >>> interests - something they might be looking for. I choose these 10 > >>> fields > >>> devided into some specific subjects. Somewhere it is too detailed, while > >>> elsewhere it is too fuzzy - it is just showing image of Pharo I have in > >>> my > >>> mind. > >>> > >>> It should help people to: > >>> - identify important classes in Pharo, > >>> - select right project, > >>> - understand what is application, tool or framework, > >>> - see what is allready inside main Pharo image. > >>> > >>> I would like to add links pointing to part of books or to videos where > >>> specific projects are used. And maybe a star symbol for very important > >>> or > >>> enterprise ready projects. > >>> > >>> As You can see I left few subjects empty. Maybe someone can help me fill > >>> this. But I will be happy for any type of correction - changing fields > >>> of > >>> interest, subjects, adding/removing projects etc... > >>> > >>> I prepared textual version on github - but right now it is not coherent > >>> with > >>> the drawing (I will correct this if needed). > >>> > >>> Adam.

Oct. 26, 2015

Re: [Pharo-users] Pharo family update

by Adam

Dne Po 26. ÅÃjna 2015 16:19:36, stepharo napsal(a): > You can safely remove Marina. > It is unmaintained, undocumented and not finished. > OK > I did not see Fuel. Could be close to STON > Would be nice to have parsers > Smacc > OMeta > PetitParser > Fuel is under Data - Storing (but I thinking about move it under Import/Export SmaCC and PetitParser are Import/Export - Parsers OMeta can be included. Adam. > Le 25/10/15 20:23, Adam a Ã©crit : > > Hello, > > > > next update. I tried to follow all sugestions - but not all is implemented > > into drawings (maybe because I did not quite understand, or I did not > > found > > enough information, or something like that). > > > > Pharo is mostly development platform, and image shows mostly libraries and > > frameworks for development, but "Development" circle in the image is more > > about tools primarly targeted to support process of development. So, if > > Gofer and Metacello is not used for this purpose (maybe it is, I'm not > > sure), it should be in "Working" circle. > > > > "Working" circle is mostly about tools and applications for "normal" > > people. Maybe it should be named like: "Desktop"... > > > > "Server" circle is meant to show that Pharo itself can offer services to > > other parties. > > > > Development/Working/Server are some kinde of trinity around it everyhing > > else is rotating. But Pharo is more about Development so other circles > > are main groups of libraries and frameworks. > > > > Adam > > > > Dne PÃ¡ 23. ÅÃjna 2015 23:58:48, Adam napsal(a): > >> Hello, > >> > >> I just updated drawing of projects around Pharo. > >> > >> Main idea is to guide people (new users of Pharo) through fields of > >> interests - something they might be looking for. I choose these 10 fields > >> devided into some specific subjects. Somewhere it is too detailed, while > >> elsewhere it is too fuzzy - it is just showing image of Pharo I have in > >> my > >> mind. > >> > >> It should help people to: > >> - identify important classes in Pharo, > >> - select right project, > >> - understand what is application, tool or framework, > >> - see what is allready inside main Pharo image. > >> > >> I would like to add links pointing to part of books or to videos where > >> specific projects are used. And maybe a star symbol for very important or > >> enterprise ready projects. > >> > >> As You can see I left few subjects empty. Maybe someone can help me fill > >> this. But I will be happy for any type of correction - changing fields of > >> interest, subjects, adding/removing projects etc... > >> > >> I prepared textual version on github - but right now it is not coherent > >> with the drawing (I will correct this if needed). > >> > >> Adam.

Oct. 26, 2015

Re: [Pharo-users] Pharo family update

by Adam

Thanks for all comments. Dne Po 26. ÅÃjna 2015 12:18:31, HernÃ¡n Morales Durand napsal(a): > 2015-10-26 11:08 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > Thanks Adam. This is a great initiative. I really like the > > internal/external distinction. > > > > A few questions... > > > > Why is "Compilers" outside the circle? I dont know :) - I dont even know if it should be included. It is part of Nautilus from this point of view. I em not aware about possiblity to choose different compiler or to compile e.g. javascript into smalltalk. > > > > What is the "VB" part of "VB-Regex" ? > > Vassili Bykov was the original author of Regex11 and later it was renamed. > > > and a few suggestions... > > > > > About categories I would group in different way but it's personal > > > > choice. Like... > > > > > Reflection > > > > It would be nice to emphasise our reflective capability, but what > > would be some subparts? > > Reflection is commonly decomposed in two parts: Introspection and > intercession. I em not sure if it fits into philosophy of the picture. Reflectivity as well as living environmet is attribute of Pharo. This picture is more about tools, applications, frameworks and libraries for Pharo. It can be pointed out in accompanying description (under Pharo logo). > > > > Code Analysis > > > > This could just be "Analysis" and include Moose and SciSmalltalk. There is Data analysis with Moose included. > > > > > Persistency > > > > Maybe "Connectors" could be renamed to "Persistence". > > Yes, besides that would avoid confusion with the Connectors package. Can be. First version contains this, but I change it because connectors to external databases are used for more then persistency. It may also allow to define model, query data, authenticate users, allows concurency etc... So persistency is now under Data/Storing > > > It would be good to promote in-Image persistence solutions since that > > is a speed advantage for prototyping. btw, Is SimplePersistance > > stable enough to be included? > > http://smalltalkhub.com/#!/~TorstenBergmann/SimplePersistence > > I don't know about SimplePersistence but in-image persistence is a cool > feature that other technologies lack. Agreed - this should be somehow in the picture. > > > I don't think Magma and SandstoneDb provide services to other clients > > (??) and so don't seem related to "Server" and would group better with > > "Connectors/Persistence". That does then leave "Server" a bit bare. > > Perhaps "RemoteFrameBuffer" would be a good fit. > > Yes, but they are able to provide service outside of running Pharo (through network), aren't they? I did not finish reading all books yet :) Maybe this is a good question. What kind of services can Pharo provide over the network (or local sockets or pipes)? Zinc as HTTP for sure (somewhere I see HTTPS branch...or TLS implementation). WEB, REST and others are covered in Web development. VNC - through RemoteFrameBuffer. Databases (direct connection without using REST)? Repository and versioning (like Smalltalkhub - but I think it uses HTTP) CORBA? What about possibility to share objects (by cloning objects or by sending messages or by using proxy objects)? (Now I em not able to think about anything else much usefull :) - SSH, NTP, IMAP, nothing like this seems to be right job for Pharo - but who knows :)) > > > > "Output" is a bit too much like "Export". Perhaps it could be renamed > > "Presentation" Can be. > > > > The legend could be moved to a corner (bottom left?), and "Pharo" > > could be moved more centrally to its place. In another shaded corner > > you might list the major repositories: > > * smalltalkhub.com > > * ss3.gemtalksystems.com > > * squeaksource.com OK.

Oct. 26, 2015

Re: [Pharo-users] TestAsserter>>assertCollection:hasSameElements:

by Peter UhnÃ¡k

On Mon, Oct 26, 2015 at 8:27 AM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Am 25.10.15 um 16:33 schrieb Peter UhnÃ¡k: > > > assert:equals: it's just more typing than #= with no additional outcome >> > > I also disagree, but that may be also because maybe we write tests for > different purpse. > If you write tests just to test your code, then whatever... I don't do > that so I can't comment on that. > > However if you do TDD, then tests are to provide feedback, and from that > perspective you want to see immediately what is the difference. If I see > that the assertion failed I have to start digging to find out what is the > difference, which is extra work and bad from feedback perspective. If I > instead immediately see what I need to see it allows me to faster deduce > the source of the problem and resolve it. > > I'm sorry, but what you are saying doesn't make any sense. Even if I > "only" want to test code (which is exactly what you do in TDD, btw.), I > need good feedback. > Well, that was a bit of generalization on my part. The point was, that many people write tests as an afterthought... which means they have different means of getting feedback from the system (e.g. logging, running manually the code, etc.). In such situation they often end up testing already mostly working code, and thus the feedback from the tests is not as important, because you end up less digging up problems (since large portion were found and resolved during manual testing). > We could think about subclassing TestFailure and a way to hand information > to the TestFailure so that a nice String can be produced. Like a method > like cull: that adds arguments' printString representation into the failure > description. > You mean #assert:description: ? Because we already have that. > Please step back for a second and think again: these are two very > different things. The job of an Assertion is to make a problem visible. The > representation of the problem is something else, even if these are closely > related. This is object thinking lesson #2 or so. > Object thinking lesson #3 tells me that I should not care about what is going on behind the curtains. And while I could explicitly separate the two, if I do it all the time I don't see what's bad about having a convenience method. (And by looking at Object or String protocol, Pharo is a lot about having convenience over engineering rigidness). But: adding more and more misnamed and misleading assertion methods makes > the use of SUnit frustrating and will make it obsolete over time. If I have > to hunt for design problems in SUnit because it assumes something to be > wrong even though my understanding of waht I tested is different, I lose > way more time than I am ready to accept. This doesn't happen to me often. > If finding that I misunderstood an assertion method means I lost a few > hours, the best thing that may happen is that I never use that method > again. In the worst case, I decide I think SUnit is useless for me. That > would be really bad, don't you think? > I am not sure if we are talking about the same SUnit. Sure, there are 32 methods in the "asserting" protocol, however most of them are either opposites of one another "#assert: vs #deny:", or they provide some customization such has "#assert:description:", "#should:raise:" ... so if I count only meaningfully different methods the number 7 (not to mention that some of the methods are not even used). But if you have trouble understanding the purpose of seven methods, then the problem is on your end, and don't blame SUnit for it. > > > > assertCollection:hasSameElements: > >> > So, let's start by asking what the question really means. Does it mean >> that one collection is a subset of the other? What about ordering then? >> Does it mean both contain the same elements at the same position or just >> the fact that if they both were Sets contained the exact same elements. The >> question itself is not exact, so how could an answer possibly be? >> > > There is no question about this method, since this is implemented in code > there is nothing ambiguous. This method effectively converts both arguments > to sets and compares them like that. > > > Sorry to say that, but this is ambiguity by design: you define > hasSameElements: as "both result in the same Set". So the name of this > assertion method is a great example of bad naming, IMO. > Yes, the naming is confusing. My point was, that instead of philosophizing about the meaning you can look at the code. Of course if you use the method for the first time (like I did), you will get burned by it (as I did). > The question is whether such thing is useful for non-sets, and there are > definitely cases where such assertion is not appropriate (when you want to > ensure that there are specific items or specific positions), that's why I > suggested asserts specifically for that. > > This is just nonsense. You name a method after a general collection class > and try to tell me that it doesn't matter that it is only suitable for Sets > and that is okay? > Nono, I am not saying that the name is good, quite the opposite. I am asking whether that method makes sense for non-sets. Because if it doesn't, then maybe we could rename it. In fact in Pharo itself nobody even uses this method (the only sender is TabManagerModelTest, where the use is NOT appropriate). > self assert: result asOrderedCollection asSortedCollection equals: (1 to: >> 10) asOrderedCollection >> > > This is what I usually do now (although I convert to Array, not > OrderedCollection, because the expected one is usually created by hand with > #() or {} ). > > I don't really care. If what you try t say is that the testing code can be > ugly and long, then I agree. If you need tests like this very often and > want something to make this easier, I understand and agree that some > additions to SUnit can be helpful. But the way this has been tried so far > seems completely wrong to me. > How would you test it then? Some problem domains deal with certain kind of problems more than others and thus benefit more from appropriate assertions. > > > Just a few weeks ago, we discussed something similar about the equality >> of two Collections. Endless discussions where people try convince others >> that their definition of equality and/or sameness is correct with no >> outcome. >> > > I don't see a problem with that because collections truly can have > different equalities based on the context and their purpose. And while you > can call this rat poison, it effectively tells what kind of behavior you > expect from the collections, which seems ok. > > So what, again, was the point of naming a method after a general > Collection class and use a question that is very unspecific? A Collection > has the same elements as another does not necessarily mean they both result > in the same set. Can we agree on that? All the question asks if all > Elements in Collection A can also be found in Collection B. The method name > states nothing more than that. > We agree that the method is badly named. (However what equality of two Collections means is context-dependent.) > My point here is that a general purpose framework like SUnit should be > free of such debatable things. SUnit has to be reliable and understandable. > There is nothing wrong with providing some "plugins" for problems like > Collections that make life easier. > It would be desirable to have more control over SUnit's feedback with > little typing. > Well but we need a way to provide context for the assertion. If I could type less then I would be happier user, however currently I don't see a way how to make it more general (so I don't need to type) and more precise (it still understands context) at the same time. So going back to your earlier suggestion with the class... you imagine something like this? self assert: a equals: b strategy: CollectionHasExactlyTheSameElementsAsAnotherAtTheSamePosition where the method would have both the definition of the assertion and a way to nicely display it? (which could be of course delegated to other parties via composition, or maybe the test assertion could specify both independently) So my question is --- how to compare collections irrespective of type, and >> possibly of order? >> >> A) always convert the actual collection toanArray >> >> I don't think it is a good idea to provide tests fro general Collections > that first convert it to some specialized Collection class. There may be > nothing wrong with doing so, but it always depends on what exactly you want > to test for. If converting to an Array is part of that test, the test is > specialized and not for Collections in general. > Seems to be an indication that your test is not a general Test on > Collections... > the purpose of the conversion was to have same type of both compared sides, because I care about the content, not the wrapper (comparing OrderedCollection to Array will always fail even if they have the same elements) C) extend TAssertable with new methods like >> >> #assertElementsOf: actualCollection equals: expectedCollection >> #assertUnorderedElementsOf: actualCollection equals: expectedCollection >> >> These names (I know, they are just examples, so I don't pick on them > specifically) are always open for interpretation. > The naming was just an example (first thing that came to my mind). Maybe we could come up with a clear name. > > C.a) directly in Pharo/SUnit >> > No. For several reasons: > * The whole discussione we're having on this > * SUnit is a framework that is cross-platform. You can never be completely > sure that a certain method on a Collection class which is not in the ANSI > standard gives you the same results on another Smalltalk > Agreed. > C.b) in independend SUnit-Extensions repository/project >> > A much better approach. But then we have a portability problem if things > like extensions and method overrides come into play. So this requires > architectural changes in SUnit to enable a plugin mechanism. That, btw, > would be a great thing! > > C.c) just in my project >> > This should surely be a starting point to stabilize things. If we had > plugins, it would be easy to publish your stuf as plugin at any time. > > >> D) stop discussing non-problems >> > If you mean others think you should just shut up and you should just do it > for yourself, then I think it is not a good option. I am quite sure your > question shows that there is a problem with SUnit. Be it with Collections > or any other area. SUnit started as something quick and dirty and thus is > not perfect for many situations. We should look for patterns and solutions. > I would definitely disagree if you suggest people might think your > questions are a non-problem! > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now to get somewhere, I think the main points emerging here are: 1. #assertCollection:hasSameElements: is a bad name, because it treats arguments as sets, not generic collections it could be renamed or removed (no code in Pharo itself uses it (only Spec, but the use there is wrong)) 2. Providing selectors such as #assertCollection:equals: and similar just to get different description may not be the best idea, which leads to point 3 3. An easy way to extend printing/assertions/plugins; but what would that look like? Maybe #assert: a = b description: [ Diff collectionDiffBetween: a and: b ] or #assert: a equals: b strategy: CollectionHasExactlyTheSameElementsAsAnotherAtTheSamePosition or something else... Peter

Oct. 26, 2015

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

by stepharo

Le 24/10/15 06:06, Peter UhnÃ¡k a Ã©crit : > > > Unless Cyril is going to do the rewrite himself. > Wasn't that the plan? I'm confused :) > > > Oh? I do not remember anyone mentioning on the mailing list that > someone will change Spec to use FT. Or was this from some internal > discussion at Inria/Synectique? It is the plan since FT was introduced. The problem was that NewList API and FT were not compatible. So we should check but no reason to keep NewList (bad design) and also if we could kill PluggableListMorph use. Stef > > Peter

Oct. 26, 2015

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

by stepharo

We should make sure that we can use FT instead of NewList (this is on my todo since ages). Stef Le 26/10/15 08:27, Edouard KLEIN a Ã©crit : > > FT is FastTable. This is a project begun by Esteban to replace the old > slow list on Pharo. > > Pharo 5 uses FastTable now. > > Thanks for the details. Should I update to Pharo5 tu use FT ? > > As for my progress in debugging things. I see that the roots and the > children behave differently (although they are created equal by my > nodeFromTreeStructure: method), for instance, root nodes are not > inspectable, when I try to see them in an inspector I get : > MessageNotUnderstood SpecTreeNodeModel>>gtInspectorMorphIn. > > Children nodes can be seen in the inspector without a hitch. > > Also, root nodes know their widget (a MorphicTreeNodeAdapter) whereas > the children return nil. > > Any help, even just a reference at someplace to look, would be > appreciated. > > On Mon, 26 Oct 2015 at 11:49 Ferlicot D. Cyril > <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: > > Le 26/10/2015 10:38, Edouard KLEIN a Ã©crit : > > What is FT ? > > > > FT is FastTable. This is a project begun by Esteban to replace the old > slow list on Pharo. > Pharo 5 uses FastTable now. > > > I did some debugging. When I send the selected:#true message to > a root > > node, it goes down to the Morphic classes, and everything is > fine, when > > I send it to a child node, the dependents array of the > TreeNodeModel is > > nil, so nobody gets the message. I don't know enough about Spec > yet to > > understand what dependents are and why there are none on a child > node. > > > > Because I really need to get this done quickly, I will try to > write a > > quick and dirty fix in a subclass that will directly talk to the > morphic > > objects underneath. > > > > Now, with some guidance from you guys, I would be really happy > to take > > some time and write some useful code that could solve this problem > > correctly, and have it commited for anyone to use. But first, in > order > > to justify to my employer that coding with Pharo was a good > choice, I > > need to make my application work. > > > > I'll update here as I go. > > > > > > -- > > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

Oct. 26, 2015

Re: [Pharo-users] Pharo family update

by Esteban A. Maringolo

Magritte could be categorized as meta-modelling. PostgreSQL, Magma, MongoDB, etc should be Databases. Persistency should include Voyage, GLORP, SandstoneDB, etc. Esteban A. Maringolo 2015-10-26 17:19 GMT-03:00 stepharo <stepharo(a)free.fr>: > You can safely remove Marina. > It is unmaintained, undocumented and not finished. > > I did not see Fuel. Could be close to STON > Would be nice to have parsers > Smacc > OMeta > PetitParser > > > Le 25/10/15 20:23, Adam a Ã©crit : > >> Hello, >> >> next update. I tried to follow all sugestions - but not all is implemented >> into drawings (maybe because I did not quite understand, or I did not >> found >> enough information, or something like that). >> >> Pharo is mostly development platform, and image shows mostly libraries and >> frameworks for development, but "Development" circle in the image is more >> about tools primarly targeted to support process of development. So, if >> Gofer >> and Metacello is not used for this purpose (maybe it is, I'm not sure), it >> should be in "Working" circle. >> >> "Working" circle is mostly about tools and applications for "normal" >> people. >> Maybe it should be named like: "Desktop"... >> >> "Server" circle is meant to show that Pharo itself can offer services to >> other >> parties. >> >> Development/Working/Server are some kinde of trinity around it everyhing >> else >> is rotating. But Pharo is more about Development so other circles are main >> groups of libraries and frameworks. >> >> Adam >> >> Dne PÃ¡ 23. ÅÃjna 2015 23:58:48, Adam napsal(a): >>> >>> Hello, >>> >>> I just updated drawing of projects around Pharo. >>> >>> Main idea is to guide people (new users of Pharo) through fields of >>> interests - something they might be looking for. I choose these 10 fields >>> devided into some specific subjects. Somewhere it is too detailed, while >>> elsewhere it is too fuzzy - it is just showing image of Pharo I have in >>> my >>> mind. >>> >>> It should help people to: >>> - identify important classes in Pharo, >>> - select right project, >>> - understand what is application, tool or framework, >>> - see what is allready inside main Pharo image. >>> >>> I would like to add links pointing to part of books or to videos where >>> specific projects are used. And maybe a star symbol for very important or >>> enterprise ready projects. >>> >>> As You can see I left few subjects empty. Maybe someone can help me fill >>> this. But I will be happy for any type of correction - changing fields of >>> interest, subjects, adding/removing projects etc... >>> >>> I prepared textual version on github - but right now it is not coherent >>> with >>> the drawing (I will correct this if needed). >>> >>> Adam. > > >

Oct. 26, 2015

Re: [Pharo-users] Pharo family update

by stepharo

You can safely remove Marina. It is unmaintained, undocumented and not finished. I did not see Fuel. Could be close to STON Would be nice to have parsers Smacc OMeta PetitParser Le 25/10/15 20:23, Adam a Ã©crit : > Hello, > > next update. I tried to follow all sugestions - but not all is implemented > into drawings (maybe because I did not quite understand, or I did not found > enough information, or something like that). > > Pharo is mostly development platform, and image shows mostly libraries and > frameworks for development, but "Development" circle in the image is more > about tools primarly targeted to support process of development. So, if Gofer > and Metacello is not used for this purpose (maybe it is, I'm not sure), it > should be in "Working" circle. > > "Working" circle is mostly about tools and applications for "normal" people. > Maybe it should be named like: "Desktop"... > > "Server" circle is meant to show that Pharo itself can offer services to other > parties. > > Development/Working/Server are some kinde of trinity around it everyhing else > is rotating. But Pharo is more about Development so other circles are main > groups of libraries and frameworks. > > Adam > > Dne PÃ¡ 23. ÅÃjna 2015 23:58:48, Adam napsal(a): >> Hello, >> >> I just updated drawing of projects around Pharo. >> >> Main idea is to guide people (new users of Pharo) through fields of >> interests - something they might be looking for. I choose these 10 fields >> devided into some specific subjects. Somewhere it is too detailed, while >> elsewhere it is too fuzzy - it is just showing image of Pharo I have in my >> mind. >> >> It should help people to: >> - identify important classes in Pharo, >> - select right project, >> - understand what is application, tool or framework, >> - see what is allready inside main Pharo image. >> >> I would like to add links pointing to part of books or to videos where >> specific projects are used. And maybe a star symbol for very important or >> enterprise ready projects. >> >> As You can see I left few subjects empty. Maybe someone can help me fill >> this. But I will be happy for any type of correction - changing fields of >> interest, subjects, adding/removing projects etc... >> >> I prepared textual version on github - but right now it is not coherent with >> the drawing (I will correct this if needed). >> >> Adam.

Oct. 26, 2015