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

Re: [Pharo-users] [OT] Bill Gross: The single biggest reason why startups succeed

by Offray Vladimir Luna CÃ¡rdenas

Thanks Jose, Sean and Steph, I think that this is an important conversation, so here are my two cents. It started small but suddenly it became long, so thanks in advance for those who read it all. May be I'm giving the details Steph asked for (may be to many details :-P). For my Smalltalk is a better way to explore ideas via digital prototypes. I have been using Linux since 1996 and have a glimpse of Smalltalk in 2005 and despite of making my MSc thesis on Squeak / Bots Inc as modeling and learning devices for collective problem solving[1] and even being an active member of the Squeakland / Etoys community as teacher and a speaker in community gatherings, the time for me at that moment was too early: Me and my students were getting older but Smalltalk didn't feel like growing with us. So I keep using Linux since that time until now. My vehicle for writing, organizing and exploring ideas via digital technologies were mainly TeXmacs[2], Leo[3], IPython[4], Wikis (MoinMoin, tiddlywiki, dokuwiki), webframeworks (web2py [4a]) and lately pandoc[5] and LaTeX. What put Smalltalk in the radar again was the start of my Ph.D research in 2010[6], at that moment as a important historical reference and an intuition, but after finishing the "theoretical" part year and a half ago (with some long pauses) I was finally able to put hands on the technology again. It was the second half 2014. I agree with Jose about Smalltalk as a different way to solve problems and to empower people by let them think different. I have witness this with myself. The problem I chose was "interactive documentation" and in my approach documents are interactive trees which can arrange writing as a "layered emergent dynamic process". I had this idea with Leo and IPython[7][7a], but the file system approach was too complex: a lot of different technologies, ways to think (data bases, procedural, imperative, declarative, and object programming), frameworks and technologies (qt, zeroMQ, javascript, JQuery, (I)Python, etc). With Pharo I can explore the same idea in a uniform, comprehensive interactive environment. This is still a pretty small ecosystem and there are not so much mature libraries (SciSmalltalk is pretty small compared to SciPython for example and web2py is easier to use that Seaside or Aida), but I can, with a little help of the community, go pretty far by myself with this idea of interactive tree-like documentation. I would like to be better and to have more time and continuity in this effort, instead of this activity rush + long pauses rhythm, but even with my time and knowledge limitations I can be more agile in testing ideas in this environment that in anything else I have tested before. It required Pharo, GT Tools, Roassal and Deep Into Pharo to feel the environment empowering for me again and it took almost 10 years from my first exposure to Smalltalk for learning and modeling in Squeak to making my first "app" for interactive documentation in Pharo, again for learning and modeling but for hackerspaces/citizens instead of universities/students. 10 years to become again an active member of the Smalltalk community (and member of the Pharo association [*]), despite of being still a newbie and writing rookie code. I would like to decrease for others this time between the first exposure to Smalltalk and the continuous use of it as a vehicle for thinking different. That's why I'm making workshops in our hackerspace and using data narratives and visualization to teach young and adults about this other tools and their ways of empowering thinking by writing/publishing differently. So, if Unix took 50 years to take the world and, in my personal story, Smalltalk took 10 years to empower my world, I would not be concerned with quick popularity, but with fluid long lasting empowerment. I think that we need to talk better with the "external" world (databases, input/output formats and operative system libraries and process, frameworks and communities) but for me the main value of Smalltalk is the way it empowers individuals and communities by being a continuous, interactive, coherent, extensible and comprehensible system to explore/express ideas by yourself and that's something you can not get easily in the Unix / file system world, because of its origins and its development history[**]. Cheers, Offray [*] I can't find myself as a member, despite of paying my year subscription. There is any way to trace what's happening? [**] About the discussion pointed by Sean on Unix, I would recommend "Unix haters handbook" [8] and Tracing the dynabook[9] for arguments about the ideas of Unix versus the ideas of the Dynabook/Smalltalk. Links ==== [1] http://mutabit.com/deltas/repos.fossil/offray-maestria-tesis/index [2] http://texmacs.org/ [3] http://leoeditor.com/ [4] http://ipython.org/ [4a] http://web2py.com/ [5] http://pandoc.org/ [6] http://mutabit.com/deltas/repos.fossil/doctorado-offray/index [7] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexi… [7a] http://mutabit.com/offray/static/blog/output/posts/la-forma-en-que-escribo-… [8] http://web.mit.edu/~simsong/www/ugh.pdf [9] http://tkbr.ccsp.sfu.ca/dynabook/ On 21/07/15 09:58, Sean P. DeNigris wrote: > Jose San Leandro wrote >> If an opinion from a newcomer is useful, I'm not so obsessed about how >> popular Smalltalk is. > Very useful, and not just a newbie opinion. On the Amber list, Richard Eng, > who is working to make Smalltalk mainstream, was disappointed by his blog > post stats. I responded in agreement with you [2]: > >> Unix, which Alan Kay describes as "a budget of bad ideas" (and I >> agree), took almost 50 years to take over the world [1]. Maybe you're 10 >> years too early to make Smalltalk popular ;) But seriously, I think you're >> using the wrong metrics. The great majority of people are instrumental >> thinkers i.e. they judge every new thing by how useful it is to their >> current goals. This is the definition of the Pink Plane. Given that the >> real value of Smalltalk is that it's prototype Dynabook software, which is >> way into the blue plane of computing, convincing the masses of its value >> is extremely unlikely - and not required! If say 10% of programmers are >> interested in the inherent value of ideas, and we capture this 10%, that >> will be more than enough critical mass. And given your report of relative >> popularity of your blog posts, 570/7000 = 8% doesn't sound too far off ;) >> >> BTW I'm not saying don't try to reach as many people as possible, only to >> reframe what failure looks like. >> >> [1] >> http://www.forbes.com/sites/timworstall/2013/05/07/is-unix-now-the-most-suc… > [2] > http://forum.world.st/A-Gentle-Introduction-to-Amber-tp4831244p4833048.html > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bill-Gross-The-single-biggest-reason-why-startups-suc… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 23, 2015

Re: [Pharo-users] Class side vs instance side

by Peter UhnÃ¡k

Cache of the mapping is just an implementation detail. I was referring to the instance of the ==MyRectangle== object; so I am more interested in this from outside perspective --- other objects that will have to use the API... So whether I would call [[[ "class-side methods" MyRectangle oppositeSideOf: #top "-> #bottom" "instance side" MyRectangle new oppositeSideOf: #top "singleton" MyRectangle instance oppositeSideOf: #top "extending symbols" #top oppositeSide "a lot of classes" Top "new/instance/whatever" oppositeSide "-> a Bottom instance/class" " or something (completely) different?" ]]] Peter On Thu, Jul 23, 2015 at 2:18 PM, Ben Coman <btc(a)openinworld.com> wrote: > Even if you put the method on the class-side, you would still be > creating an new instance each time. Maybe you can store it in a class > variable... > > MyRectangle>>oppositeSides > ^ oppositeSides ifNil: [ oppositeSidesCache := { #top -> #bottom. > #bottom -> #top. > #topLeft -> #bottomRight > .... > } asDictionary ]. > > cheers -ben > > On Thu, Jul 23, 2015 at 8:40 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > > > I am trying to figure out where to best place some mapping/data/stable > > methods. > > > > For example imagine method > > ~~~~~~~~~~~~~~~~~~~~~ > > MyRectangle>>oppositeSides > > ^ { #top -> #bottom. > > #bottom -> #top. > > #topLeft -> #bottomRight > > .... > > } asDictionary > > ~~~~~~~~~~~~~~~~~~~~ > > > > And then the class might have some other related methods such as > > ~~~~~~~~~~~ > > MyRectangle>>oppositeSideFor: aSide > > ^ self oppositeSides at: aSide > > ~~~~~~~~~~~~ > > > > So it's a method returning a mapping between opposite sides/corners and > thus > > is really not going to change. > > Now I could place this in instance-side and create a new instance every > time > > I wanted to use it (which doesn't seem practical), or I could put it in > > class-side. > > The problem I have with class-side is that naming is more like going > through > > minefield (more than once I corrupted my image by naming a method or > > variable something I shouldn't have), and for whatever reason it feels > like > > either metaprogramming or procedural programmming... That class side > methods > > are pretty much global functions/variables... and short of constructors > I am > > avoiding static methods even in other languages... but maybe using it is > ok. > > Or maybe have it object an use singleton? > > > > The only oop-like approach I see would be to extend symbols (#top > > oppositeSide), or have separate objects for sides, but that seems like > > overkill. > > > > MySide subclass: #Top > > > > Top>>oppositeSide > > ^ Bottom new > > > > Are there any best practices regarding this? This is also true for actual > > data stored in methods/attributes (such as icons). > > > > P.s.: For english natives... Should the second method be ned > > "oppositeSideOf:" or "oppositeSideFor:"? > > > > Any ideas/pointers appreciated, > > Peter > >

July 23, 2015

Re: [Pharo-users] Class side vs instance side

by Ben Coman

Even if you put the method on the class-side, you would still be creating an new instance each time. Maybe you can store it in a class variable... MyRectangle>>oppositeSides ^ oppositeSides ifNil: [ oppositeSidesCache := { #top -> #bottom. #bottom -> #top. #topLeft -> #bottomRight .... } asDictionary ]. cheers -ben On Thu, Jul 23, 2015 at 8:40 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > I am trying to figure out where to best place some mapping/data/stable > methods. > > For example imagine method > ~~~~~~~~~~~~~~~~~~~~~ > MyRectangle>>oppositeSides > ^ { #top -> #bottom. > #bottom -> #top. > #topLeft -> #bottomRight > .... > } asDictionary > ~~~~~~~~~~~~~~~~~~~~ > > And then the class might have some other related methods such as > ~~~~~~~~~~~ > MyRectangle>>oppositeSideFor: aSide > ^ self oppositeSides at: aSide > ~~~~~~~~~~~~ > > So it's a method returning a mapping between opposite sides/corners and thus > is really not going to change. > Now I could place this in instance-side and create a new instance every time > I wanted to use it (which doesn't seem practical), or I could put it in > class-side. > The problem I have with class-side is that naming is more like going through > minefield (more than once I corrupted my image by naming a method or > variable something I shouldn't have), and for whatever reason it feels like > either metaprogramming or procedural programmming... That class side methods > are pretty much global functions/variables... and short of constructors I am > avoiding static methods even in other languages... but maybe using it is ok. > Or maybe have it object an use singleton? > > The only oop-like approach I see would be to extend symbols (#top > oppositeSide), or have separate objects for sides, but that seems like > overkill. > > MySide subclass: #Top > > Top>>oppositeSide > ^ Bottom new > > Are there any best practices regarding this? This is also true for actual > data stored in methods/attributes (such as icons). > > P.s.: For english natives... Should the second method be ned > "oppositeSideOf:" or "oppositeSideFor:"? > > Any ideas/pointers appreciated, > Peter

July 23, 2015

Seeking help to resolve startup error on CI automated build

by Jigyasa Grover

HiI am trying to build my first application in Pharo i.e. an offline text search application namely *searchQuick* which returns the list of file titles from the pre-loaded text files present in the resource folder when a string is searched for. You all are welcome to fork the code (https://github.com/jig08/sQuick_new) , try the infancy application and send in suggestions. Currently, I have put my application up on CI for automated build. I am currently getting a StartUp error on VERSION=development (40) The error is as follows: *The symbolic version '0.1-baseline' is not defined in ConfigurationOfsQuick_new for the current platform. Possible symbolic version values include: #(#bleedingEdge #development #stable)* I have checked ConfigurationOfsQuick_new and the corresponding method reads as follows:*------------------------------------------------------ development: spec <symbolicVersion: #'development'> spec for: #'common' version: '0.1-baseline'*.*------------------------------------------------------* It would be great if my mistake is pin-pointed and I could resolve it. Thanks and Regards Jigyasa

July 23, 2015

[MCGitHubRepository] Seeking better options to access resources folder from github repo

by Jigyasa Grover

Hi I am trying to build my first application in Pharo i.e. an offline text search application namely *searchQuick* which returns the list of file titles from the pre-loaded text files present in the resource folder when a string is searched for. You all are welcome to fork the code (https://github.com/jig08/sQuick_new) , try the infancy application and send in suggestions. So far, to access the resources folder from my github repo, I have been using the following code snippet: *----------------------------------------------------------------------------------------------------------------* *| resourceFolder resourcePath|* *MCGitHubRepository allSubInstancesDo: * * [ :repo |* * repo projectPath = 'jig08/sQuick_new' * * ifTrue: [ resourcePath := repo directory ] * * ]. * *resourceFolder := resourcePath / 'sQuick_new/resources'.* *----------------------------------------------------------------------------------------------------------------* I wanted to know a better option that could be used to access it, without checking all the entries present for a correct match i.e. not use *"**MCGitHubRepository allSubInstancesDo:"* Help Appreciated Thanks Jigyasa

July 23, 2015

Class side vs instance side

by Peter Uhnak

Hi, I am trying to figure out where to best place some mapping/data/stable methods. For example imagine method ~~~~~~~~~~~~~~~~~~~~~ MyRectangle>>oppositeSides ^ { #top -> #bottom. #bottom -> #top. #topLeft -> #bottomRight .... } asDictionary ~~~~~~~~~~~~~~~~~~~~ And then the class might have some other related methods such as ~~~~~~~~~~~ MyRectangle>>oppositeSideFor: aSide ^ self oppositeSides at: aSide ~~~~~~~~~~~~ So it's a method returning a mapping between opposite sides/corners and thus is really not going to change. Now I could place this in instance-side and create a new instance every time I wanted to use it (which doesn't seem practical), or I could put it in class-side. The problem I have with class-side is that naming is more like going through minefield (more than once I corrupted my image by naming a method or variable something I shouldn't have), and for whatever reason it feels like either metaprogramming or procedural programmming... That class side methods are pretty much global functions/variables... and short of constructors I am avoiding static methods even in other languages... but maybe using it is ok. Or maybe have it object an use singleton? The only oop-like approach I see would be to extend symbols (#top oppositeSide), or have separate objects for sides, but that seems like overkill. MySide subclass: #Top Top>>oppositeSide ^ Bottom new Are there any best practices regarding this? This is also true for actual data stored in methods/attributes (such as icons). P.s.: For english natives... Should the second method be ned "oppositeSideOf:" or "oppositeSideFor:"? Any ideas/pointers appreciated, Peter

July 23, 2015

Re: [Pharo-users] [OT] Bill Gross: The single biggest reason why startups succeed

by stepharo

Hi jose Thanks for this interesting testimony. Le 21/7/15 12:08, Jose San Leandro a Ã©crit : > If an opinion from a newcomer is useful, I'm not so obsessed about how > popular Smalltalk is. > > I came to Smalltalk because a friend of mine (Rafa Luque) was > enthusiastic about it, and suggested me to try it. > The candy was not to build applications faster, but to think > differently, to question what and how we approach problems with > mainstream, industry "best practice" technologies and languages. > > I see Smalltalk more like what security researches think of their > discipline: it's a process, not a list of tools or recipes. After > almost two decades of developing commercial software for others and > open-source projects (mainly) for myself, using mostly Java but also > Lisp, Smalltalk has blown my mind. Could you give an example? Because I have problem to understand (since I'm born with a lisp, did my studies with an object lisp and found Smalltalk (yet another object lispish). > That wouldn't have happened if I'd tried Seaside just because I wanted > to try a different web framework. > > In my case, to approach Smalltalk I needed a certain state of mind. > You have to be aware programming is not memorizing design patterns and > pay for an IDE to do most things for you, including to check for > non-functional stuff nobody seems to care about. We're in the "i'm > proud to be lazy" era. I've seen smart people reject Smalltalk just > because they don't seem to care about what they do, or at least they > don't want to invest their time and energy. > > Probably there's a way to convert Pharo in node.js or Go, to make > people use Seaside instead of ruby on rails. More people potentially > means more financial support, and a better, sooner, full-featured, Pharo. Would be nice :) I think that having powerful libraries never hurts. This is why the stack sven is building is great. > But even then, Smalltalk empowers people to think differently and > gives the means to do so, and to promote that has to tackled differently. > I'd focus on how using Smalltalk gradually makes you a better > professional, before blaming ourselves for not yet providing > sophisticated frameworks anyone can use even if they don't know what > they're doing. :) Again I need examples Because you come from outside so this is obvious but for me I have problem to make what you say explicit. I would like to use your experience when I'm teaching :) > > Let's take the Scala or the Git case. What made people invest in > learning them was, at least in part, that they felt smarter. :) > We should focus on that: comparing how the same problem is solved in > other languages. Showing what live programming is. Don't be humble > just to be polite. > > On the other hand, Smalltalk enables us to face problems that are > potentially unachievable in other languages / ecosystems. Let's define > on a "Pharo way to do X", which inevitably starts building a > domain-specific browser, a custom IDE, and recipes for common scenarios. > > In summary, as Martin Bahr says, it's critically important to ensure > we can survive indefinitely until the perfect "timing" arrives. But > don't punish ourselves too much for not being popular. For me, the > greatest value lies elsewhere. Thanks. For me I just want to build a great system and step by step we are doing it. So exciting: small kernel, new graphics, vector graphics, cool web stack, better tools.... The pieces are coming together. > > > 2015-07-21 3:14 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>>: > > Martin BÃ¤hr wrote > > did smalltalk miss its chance, so we should give up? > > or is it still coming? glass bowl anyone? > > Using Unix - which took 50 years to takeover the world - as a > metric, we > should be hitting our stride in about 2030 ;) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Bill-Gross-The-single-biggest-reason-why-startups-suc… > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > >

July 22, 2015

Re: [Pharo-users] Smalltalkhub permission denied

by stepharo

Yes from time to time we have this problem... Le 22/7/15 04:10, Hilaire a Ã©crit : > Hello, > > On a freshly created project I have permission denied to write on the repo. > http://smalltalkhub.com/#!/~HilaireFernandes/Tools > > Hilaire >

July 22, 2015

Re: [Pharo-users] New pretty printer Blue Ink

by Martin Dias

On Wed, Jul 22, 2015 at 11:41 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 22.07.2015 um 11:27 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Nice. > > > > All this new stuff (decompiler, formatter), what's next (new changes log > ? ;-). > > > That is a very good question. When will Epicea be integrated? The current > stuff is broken anyway so less chance to worsen things :) > I hope we can integrate it soon. One of the points that delayed the integration is that we shouldn't have two overlapping mechanisms to log changes in the 5.0 release (traditional .changes/.sources file + Epicea). Then, I have made many small refactorings in Pharo 5.0 towards making the whole .changes thing removable. In particular, I tried to encapsulate reads/writes to the changes files, the uses of RemoteString, and others, into SourceFileArray (as a kind of faÃ§ade). A more clear and concentrated API in SourceFileArray is helping to understand how this thing works and how it could be removed and replaced. For example, SourceFileArray was a subclass of collection and there were many "SourceFiles at: 2" spread in the image to access the .changes file. Currently those are fixed but there is still some work to do. But I do believe we can have a removable .changes thing for Pharo 5 :-) MartÃn

July 22, 2015

Re: [Pharo-users] New pretty printer Blue Ink

by Franck Warlouzet

> From: sven(a)stfx.eu > Date: Wed, 22 Jul 2015 11:27:46 +0200 > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] New pretty printer Blue Ink > > Nice. > > All this new stuff (decompiler, formatter), what's next (new changes log ? ;-). New groups in Nautilus too, currently they are full of bugs and strange things. I am cleaning them up, I hope I will soon be done so you can use them. Franck > > On 22 Jul 2015, at 10:44, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > > > Hello everyone, > > > > We just integrated Blue Ink, the new pretty printer, in the latest Pharo 5 image ! Basically what was working still is and what was not well now is. > > > > It is not yet enabled by default, we will wait for feedbacks first. If you want to try it, just type : > > > > RBProgramNode formatterClass: BIConfigurableFormatter. > > > > BIConfigurableFormatter formatAsYouReadPolicy: true > > > > Feel free to contact me via the mailing list or personnal mail if you experience a strange behavior. I tried to improve all of them but with you I am sure all the cases will be treated in an exhaustive way. > > > > Thanks for testing it, I hope it will convince you to use format as you read in Nautilus or just automatically format your code. > > > > Franck > >

July 22, 2015