- Pharo-users - lists.pharo.org

Re: [Pharo-users] pharo and ui again

by Johan Fabry

Kilon, itâs not nice of you to say that I have a problem. I have an opinion, not a problem. And Iâm saying that we have 4 developers at most, not 10. > On Feb 12, 2015, at 14:35, kilon alios <kilon.alios(a)gmail.com> wrote: > > And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us. > > So how exactly are you going to convince 10 people to work on the GUI API of your choosing ? Are you going to pull out the argument that all theses APIs are doing more less the same thing ? Good luck convincing them. I will certainly not be one of them when the center of my philosophy is "the devil is in the details". > > All pharo developers may end up focusing on Spec for example will be enough reason for me to consider abandoning Pharo because I don't like Spec. Most likely I wont because I will find a way not to have to use it but you get my point. > > Coding is not there just to satisfy practical needs (because otherwise I would not even being using Pharo) its even more about personal taste , this is why we have tons of programming languages and even more libraries. Also the bigger the library it is the slower it moves because of backward compatibility and having to make happy a big user base. You want to add a new feature ? Sure can do . You dont like the general design ? Oops sorry you are out of luck. > > Personally I like Morphic, I heavily dislike Spec and the verdict is open for Bloc. I will have to use Bloc on a project to make up my mind but so far I have been told that Bloc is a work in progress in early stages. So for me the situation is crystal clear Morphic all the way and if I find something I don't like, subclass and improve. > > But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone. And I am glad they dont. But in any case I would not want to force my opinion on other people and instead I recognize that people want different things. > > So I definitely approve of many options and I also approve that pharo core developers try to make Pharo more modular to make it easier to mix different libraries together , I think that will be so awesome. > > On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry(a)dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>> wrote: > >> On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple, >> >> GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed. > > > I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4. > > I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own. > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by kilon alios

And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us. So how exactly are you going to convince 10 people to work on the GUI API of your choosing ? Are you going to pull out the argument that all theses APIs are doing more less the same thing ? Good luck convincing them. I will certainly not be one of them when the center of my philosophy is "the devil is in the details". All pharo developers may end up focusing on Spec for example will be enough reason for me to consider abandoning Pharo because I don't like Spec. Most likely I wont because I will find a way not to have to use it but you get my point. Coding is not there just to satisfy practical needs (because otherwise I would not even being using Pharo) its even more about personal taste , this is why we have tons of programming languages and even more libraries. Also the bigger the library it is the slower it moves because of backward compatibility and having to make happy a big user base. You want to add a new feature ? Sure can do . You dont like the general design ? Oops sorry you are out of luck. Personally I like Morphic, I heavily dislike Spec and the verdict is open for Bloc. I will have to use Bloc on a project to make up my mind but so far I have been told that Bloc is a work in progress in early stages. So for me the situation is crystal clear Morphic all the way and if I find something I don't like, subclass and improve. But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone. And I am glad they dont. But in any case I would not want to force my opinion on other people and instead I recognize that people want different things. So I definitely approve of many options and I also approve that pharo core developers try to make Pharo more modular to make it easier to mix different libraries together , I think that will be so awesome. On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)gmail.com> wrote: > > All of the above frameworks have tons of users so one thing that this > shows us is that fragmentation is really beneficial to a community. The > reason is simple, > > GUI is so complex subject but there will never be one ring to rule them > all. Many have tried, all of them have failed. > > > I donât agree. If we would have more than 10 developers working on GUI > frameworks in Pharo this may be the case. But we donât have this number. If > we are very lucky we may have 4. > > I would rather have 4 persons pulling a large cart in the same direction, > instead of 4 of them pulling their own cart (1/4th the size) in > more-or-less the same direction (if at all) as the other guys. In the first > case a lot more progress will be made. If there is something wrong with the > cart, fix it! Do not waste all this time building your own. > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

> On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)gmail.com> wrote: > > All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple, > > GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed. I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4. I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

> On Feb 12, 2015, at 07:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 12 Feb 2015, at 00:46, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> But much howtos or tutorials widely scattered and aren't up to date. > > Johan Fabry's talk at the Pharo Days was an excellent introduction to Spec, watch it. Well, thank you very much for the recommendation :-). Are the videos of the talks online? I did not see an announcement for that, and Iâd like to see some of the talks I missed on Friday due to being stuck in the Douai snow ... ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

Hi Sebastian, Iâm on holiday, so I will be brief with my replies, I hope you understand ;-) Spec is the official way to go for building UIs in Pharo: - With Spec you can write your example in 30 minutes, it just needs 1 class with 4 instvars and 3 short methods. - Most advanced documentation is a work in progress that is online here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> - The interested locals should be able to continue working on that without too many issues. (send asSpecAdapter. to the morph) - If there is no Spec widget (ComposableModel subclass) for what you want to do, you can compose Morphs as well. If you have specific issues with layout behaviors in Spec please report them on the mailing list so we are aware / we may propose solutions. Success! > On Feb 11, 2015, at 23:28, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > > Hi again! > > Well, we had an other Software Smalltalk Night and we want to try to make a Smalltalk Kinect Fun project. > It was pretty easy to conenct the Kinect camera with a Squeak For Scratch image. > That enabled everybody to easily get going. > > Since a few days I try to prepare further steps and I must say,... I am completely lost in the UI frameworks. > > Let's have a simple example. > > A window with a title, 2 labels, 2 entry fields, one checkbox and 2 buttons. > e.g. a login form for a Pharo application. > We will need the parts, the layout, the events, the starting point as well as a result handler.... > After 5 days I can tell ,that I am lost in Morphic, UIManager, Traits/No-Traits, Spec, GLMMorphic, Poly.... > And sometimes things are even mixed up and I am not able to decide which approach to follow,... > Some examples store widgets in instance variables, others initialize the morph based on the underlying model. > MVC is sometimes mixed up... > And this was just the topic parts and partially layout and events.... > How does one open this login as an overlay, or as temporary replacement for the main content.... > > I tried Spec, but somehow it is much more difficult to get a proper functioning layout that behaves mature during resize and such events than expected. > Is it possible to take a more Squeakish approach and just instantiate ui components compose them, define handler/callback symbols in those instances and then generate a specification/code out of this? > > Can anybody please point me at a full documentation on how to do things properly? > There are many examples for the widgets but there is not a single example on how to built a real framework based on MVC in Pharo. > Well and unfortunately a lot of stuff is outÃdated already. I somehow have the feeling that one and the same thing was implemented over and over again. > > I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I feel like the UI development removes all the productivity that one usually has with Smalltalk. > > I'd like to provide the interested locals here with a bsic implementation that they will be able to extend or go on with. > But I do not want to invest time into not supported things. > > Thank you for any hint again! > Sebastian > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] Getting notified when a morph moves

by Stephan Eggermont

Thanks Hilaire, that works fine. I can add the listener when the actual dragging starts and remove it on mouseUp. MDShape>>doDrag: aMouseMoveEvent with: aMDShape ActiveHand addEventListener: self. aMouseMoveEvent hand startDrag: aMouseMoveEvent with: aMDShape. MDShape>>handleListenEvent: anEvent anEvent isMouse ifFalse: [ ^self]. anEvent isMouseUp ifTrue: [ ActiveHand removeEventListener: self ]. anEvent isMouseMove ifTrue: [ self moved ] MDShape>>moved connectors do: [ :connector | connector moved ] Stephan

Feb. 12, 2015

Re: [Pharo-users] GSOC 2015 application

by Martin BÃ¤hr

Excerpts from stepharo's message of 2015-02-12 08:21:07 +0100: > we maintain one single list for pharo topics (related or not to GSOC) > I will not edit your item but you can do a pull request :) > https://github.com/pharo-project/pharo-project-proposals how can i preview changes i make? also it seems that http://topics.pharo.org/ is not being updated. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Feb. 12, 2015

Re: [Pharo-users] GSOC 2015 application

by Sebastian Sastre

nice! I've never heard about that before. Thanks for the heads up Stef! Added entries should go to the bottom or at the top? from mobile > On 12/02/2015, at 05:21, stepharo <stepharo(a)free.fr> wrote: > > Sebastian > > we maintain one single list for pharo topics (related or not to GSOC) > I will not edit your item but you can do a pull request :) > > https://github.com/pharo-project/pharo-project-proposals > > Stef > > Le 11/2/15 19:37, Sebastian Sastre a Ã©crit : >> Okay here comes some notes Iâve compiled: >> >> >> VOSS for Pharo >> http://voss.logicarts.com/ >> Implications: a completely object oriented database industry proven would have a legacy and a open sourced release empowering Pharo users and startups to stay object oriented even when persisting data. >> VOSS has dual license commercial and GPLv3, John, VOSS author already offered himself to mentor porters. >> https://www.linkedin.com/in/johnclapperton >> >> SQLServer client for Pharo >> Implications: some applications that have this dependency needs to extend and modernize features are challenged by this dependency that Pharo cannot use in a production ready state. >> >> SQL Alchemy for Pharo >> Implications: Big-data is a growing market that is easy to mine with a tool like Pythonâs SQL Alchemy. A Pharo version of such powerful tool would open this market opportunity for people wanting to offer Pharo-based solutions in this segment. Smalltalkâs syntax and tooling superiority could provide a significant push forward in this technology competitiveness because they might empower Pharo users to deliver solutions faster. >> http://www.sqlalchemy.org/ >> >> Remote Environments for Pharo >> Implications: being able to inspect, browse and debug reliably a server Pharo image from a client Pharo image would spark countless possibilities. Some of them: server maintenance; hot debug on GUI-less servers in production; live develop or debug remotely mobile devices that doesnât have a server. Hot changes in Pharo powered drones and robots. >> >> Pharo on mobile >> Implications: Is not that mobile is a growing market, is more like mobile is going supernova: http://a16z.com/2014/10/28/mobile-is-eating-the-world/ >> The power of Pharo and its libraries on mobile devices is currently perhaps one of its biggest opportunities. >> >> Deep learning for Pharo >> Implications: Robotics, drones and the internet of things will gather data from sensors that will need interpretation and modelling. All sorts of AI will use deep learning techniques and Pharo would be a great orchestrator of that modelling. >> http://www.quora.com/What-is-the-best-deep-learning-library-at-the-current-… >> >> Pharo Hadoop client >> Implications: Apache Hadoop can scale from single server to thousands of servers. The explosion of sensors, drones and mobile devices and printed devices with sensors are going to generate incredible amounts of data to process and model. Hadoop is a good fit for that and Pharo can empower faster modelling and orchestration of what to do with all that information stored in this widely adopted Hadoop technology. >> http://wiki.apache.org/hadoop/PoweredBy >> >> Cross platform Native Widgets for Pharo >> Implications: The web is fantastic but at the same time there is a big pressure to create great native applications due to the improved User Experience that the native widgets can provide. Making Pharo to create them via things like wxWidgets (https://www.wxwidgets.org/about/screenshots/) would instantly create opportunities to develop fast applications with a great UX. >> >> Protips site for Pharo >> Implications: I might spark the beginning of a mentoring ecosystem. StackOverflow is great but at the same time for a niche like Smalltalk it might not be enough to show the problem-solving potential of the platform. A site dedicated to share pro tips centered on Pharo would slowly a steady show the platformâs value. The site has to be social friendly. Each tip should have an author that can set there StackOverflow, LinkedIn, facebook, twitter or any social profile she wants. Requires nice branding and UX/UI design. Optional variation of the same idea: make it for any Smalltalk dialect instead of only Pharo. >> >> REPL IDE for Pharo >> Implications: Smalltalkers are used to very powerful IDEs. What if we have to put Pharo in a really underpowered or monitorless device? Having a powerful REPL IDE that can evaluate expressions, inspect and debug, would empower users to still do things in mini-devices during the incoming tide wave of internet-of-things. >> >> A GUI builder for Pharo >> Implications: If whatever you are doing you cannot make it visual easily, people cannot perceive it easily. Due to evolutionary reasons, our brain has unfair bias towards visual processing. Lets make something that allows Pharo to create visual things easier. Something like PARTS or Dolphin Smalltalk GUI builder would be huge. >> >> best! >> >> o/ >> >> >>> On Feb 11, 2015, at 12:14 PM, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: >>> >>> Excerpts from Stephan Eggermont's message of 2015-02-11 15:05:14 +0100: >>>> Sebastian wrote: >>>>> Can I brainstorm a wishlist? I could get wild on it :D >>>> >>>> Sure, as long as it is projects that you would be willing to mentor, >>>> and sized like they could fit. >>> >>> well, someone else could be willing to mentor then, so i don't think it hurts >>> to get wild on ideas, as long as accepted ideas come with a mentor. >>> >>> greetings, martin. >>> >>> -- >>> eKita - the online platform for your entire academic life >>> -- >>> chief engineer eKita.co >>> pike programmer pike.lysator.liu.se caudium.net societyserver.org >>> secretary beijinglug.org >>> mentor fossasia.org >>> foresight developer foresightlinux.org realss.com >>> unix sysadmin >>> Martin BÃ¤hr working in china http://societyserver.org/mbaehr/ >

Feb. 12, 2015

a successful success story

by Alain Busser

It is in French so I try to translate some parts. My goal was to teach as fast as possible the binomial distribution (number of successes when independently repeating a Bernoulli experiment) to students who, either have never seen an algorithm, or have seen some algorithmics in math lessons and don't like it at all. Both categories loved what I did with them. I precise that almost all of them are allergic to english language. The assignment was "throwing 10 dices, what is the probability of having at least 2 times "6" around the 10 results?" The whole job is related here: http://irem.univ-reunion.fr/IMG/pdf/binomiale.pdf (but I did only pages 1-5 in one hour) The first step was to show how one can simulate the throwing of 10 dices. I can do it without having to make a variable vary (explicitely at least), thanks to Seymour Papert: 10 timesRepeat: [ Transcript show: (6 atRandom)]. Then I spoke about the usefulness of the Bag object when there are statistics: Adding the 10 results (small integers) inside a Bag makes it an object where one can see and count the 6es: | urn | urn := #( ) asBag. 10 timesRepeat: [ urn add: (6 atRandom)]. Transcript show: urn. (Why "urn"? This is the word used by Bernoulli, he was thinking about balls concealed inside a vase for which the latin word was "urna"; the balls where called "billets" by Condorcet, so that they could instead be pieces of paper; whatever they were, a vase was use to conceal them) Then there remains only one difficulty: How can I automatize the counting of the 6es inside the bag? There is the most frightening challenge: Use a block with students who have never seen Pharo before. Very good surprise: They didn't seem to find this that difficult, I just had to say that 1. The pipe symbol means "such that" like in my lessons 2. The first time I use the letter "x" I have to tell Pharo that it is yet no variable to evaluate, hence the need to precede it with a colon. With that in mind, counting the 6es is the same as counting the x-es such x equals 6: | urn | urn := #( ) asBag. 10 timesRepeat: [ urn add: (6 atRandom)]. Transcript show: (urn count: [ :x | x=6]). Afterwards it remained only to repeat the whole experiment and, instead of showing the number of 6es, adding it to another bag called "stats", then displaying this bag. The end was made with a tool which exists only in mathsOntologie: The displaying of a bar chart in a translucent Morph, so that the most rapid of the students could compare several bar charts by superposition and guess the shape of the distribution. Once again, they all loved it, either because they found Pharo a better tool than whatever they knew before (and disliked), or because they knew nothing similar before (one exception: A girl who never learned algorithmics but just happens to love playing with a computer, here she is: http://reunion.la1ere.fr/2014/06/04/miss-reunion-muriel-roger-candidate-nde… ). I insist on the fact that they never saw anything like Smalltalk before, and did not seem to "rtfm": Is it because Smalltalk is a natural language or because MathsOntologie mimics the french language, I lack elements of comparison to answer to this. But I insist also to say that these students seem to dislike probability theory too. Finally, some stats about these stats: I can rapidly find the bugs when the text appears in red, and most of the time a point was missing at the end of a line, or a right bracket was missing or misplaced. Sometimes they add a space inside a word like asBag which becomes "as Bag". Alain Busser IREM La RÃ©union

Feb. 12, 2015

Re: [Pharo-users] SmaCC: First steps

by Trygve Reenskaug

The problem with reading class oriented code (C++, Java, C#, Ruby, ..., Smalltalk) is that the code does not reveal how the system will work at runtime (polymorphism). The essence of object orientation is that objects collaborate to achieve a goal. The DCI programming paradigm adds code for how the system works at runtime: * A class says everything about the inner construction of an object but nothing about how it is used in its interaction with other objects. * The new DCI context says everything about how objects are used when interacting with other objects but nothing about their insides. Class and context separates the code into two materially independent concerns: What the system IS (classes) and what the system DOES (Contexts). BabyIDE is a programming environment that supports the DCI paradigm. It is available in Squeak 4.5 and may be available in Pharo later. Cheers --Trygve On 11.02.2015 18:36, kilon alios wrote: > Well I tried in the past to use openqwaq , but what I learned from the > experience is that sometimes understanding others code can be even > more time consuming than remaking it yourself. I spent like an > afternoon trying to understand openqwaq before starting Ephestos from > complete scratch. Suffice to say that in another afternoon I had the > prototype of Ephestos working with the ability to send simple python > strings to the cptyhon interpreter to be execute by the time I was not > even able to understand the basic architecture of openqwaq. > > The module you recommended alone contains like 11.000 lines of code. > Thats a lot of work to just read that code and I cant find any class > named CModel. In any case I like it that I started from scratch, I > want to keep my project small, light, well documented and super easy > to hack. Even if that means less features :) -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27

Feb. 12, 2015