- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] playground vs workspace

by stepharo

go go go change the game :) Stef Le 8/12/14 13:26, Tudor Girba a Ã©crit : > Hi, > > We do not yet have an IDE (where I stands for integrated). We have a > set of tools and some of them are quite strong. But, we do not have an > overall experience yet. > > Yes, the underlying language model does offer a beautiful experience, > but the experience of the tools is far from that. We need tools that > are not just powerful in the hands of few specialists, but tools that > are beautiful and pleasurable to use in the hands of many. This is the > goal. > > When we will get that, I believe we will change the game. > > Cheers, > Doru > > > > On Mon, Dec 8, 2014 at 9:36 PM, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > "Our "battle" is with the non-Smalltalk world. This is what we > need to convince. And that world does not care about the history > of Smalltalk. It cares about how we can solve their problem. > That's all." > > But you already offer an impressive arsenal of tools. The world > can complain for several things but what it cannot complain is > that Pharo as an IDE is not really powerful as a whole. Your > competition would be I assume specialised tools that come as third > party. There is no IDE I know out there that offers the level of > refactoring of Pharo, in terms of tools and libraries. > > Also we should not forget that those tools are not just powerful > as is the example of GTPlayground but are engineered in such way > to cooperate which each other with ease. While on the other hand , > tools for other programming languages are by default separate and > independent and not necessarily play nice with each other which > the price one pays to keep things modular and unattached to a > specific language or IDE. So the way I see it Pharo already is > beyond competition. > > Unless of course you refer to a comparison tool per tool, which > mean you take this pharo tool and you compare with another tool > for another language out there. That case would very difficult for > you because there are tons of development tools out there. > > But the overall idea that is "hey there I give you a language, > take this enviroment too, live coding, how about an IDE and also > get these coding tools too " is really a dreamy situation already. > > The question is how badly coders want a very powerful IDE at least > the level of Pharo. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Dec. 10, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

> > With all due respect for the other Smalltalk (inspired or genuine) > environments, I have no intention of waiting for them in order to > define the way forward. + 10000 > Our "battle" is with the non-Smalltalk world. This is what we need to > convince. And that world does not care about the history of Smalltalk. > It cares about how we can solve their problem. That's all. + 10000

Dec. 10, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

For me a note can be a program. An expression that I want to get around and if I write it in a workspace and not in the system browser this is because I want it So workspace should be rename Sticky Le 9/12/14 05:46, Sean P. DeNigris a Ã©crit : > stepharo wrote >> I would like to have playground be named playground and that we keep >> "workspace" but I would like to change the name to "SimpleNoteEditor". > I like this idea, but think it needs to be developed further. For instance, > I would expect syntax highlighting and code completion to be off in a note > editor - something like the behavior of the browser's comment pane. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/playground-vs-workspace-tp4794667p4794968.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 10, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

You see for me the old "workspace" is where I type stuff that I want to keep around because in the textEditor I can do the same but when I click they go away :) For example I often do not care about inspecting the result of what I typed and I do not want something complex. So to me the old workspace is "sticky" before stickies came to live. While the systemeditor provides the same execution model it does not offer to me the same stickiness. Setf Le 8/12/14 06:20, Tudor Girba a Ã©crit : > Hi, > > Please look at the mail I sent to Torsten for a more thorough > description of my reasoning. For example, I do not like that it > implies that this is *the* place where work happens, and this is > clearly not the case. > > Yes, I use the playground extensively for so many use cases. I do not > miss the Workspace at all and I do not use it since 2 years. > > Cheers, > Doru > > > On Mon, Dec 8, 2014 at 2:56 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > Hi Doru, > > I do not understand exactly what the difference isor why you > wouldn't call GTPlayground " a Workspace". > > As I think you are using GTPlayground very extensively: > Do YOU use the Workspace at all ? > Do YOU miss something in GTPlayground, where you would say: "Yes, > only a workspace should do this". > > > Nicolai > > > 2014-12-08 7:18 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Hi, > > As you might see, the GTPlayground is called playground not > workspace. The main reason for this is that workspace implies > the place where work is done, and work is typically associated > with creating code. > > This is not the intention of the workspace. > > Workspace also comes with a history that is associated with > actual implementations. While the current GTPlayground might > appear to be similar to the workspace, I think the way you can > use the latter produces a significant shift. > > Furthermore, I think the term playground is more inline with > the idea of "playing with live objects". And, in the future, > the implementation will likely evolve towards even more > liveliness. > > It is for this reason that I would prefer that the World menu > item gets renamed to Playground. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Dec. 10, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

> This is precisely the way we should look at tools: we should identify > why we need that tool, but not necessarily stick with the tool. > > For example, people said a while ago that the Workspace is better than > the Playground for searching for things like implementors. While that > might have been the case at that time, I think that use case is better > served by the now existing Spotter. > > It is important to understand the goal and not focus at the > implementation. This is the prerequisite for inventing something new. > That is why I keep on asking stupid questions like: "Why do you need > this?" "When do you need this?" > > Coming back to your point, I think that "note tracker" is one of the > last use cases people use a Workspace for. I find this very > interesting even if I do not necessarily have this requirement for > myself. I think at the moment we can keep a renamed Workspace for > that, but in the future we will probably end up with something else. > The use case is noted in my book :) :) And we can always move the txWorkspace into txExamples packages for simple examples :) > > Cheers, > Doru > > > > On Mon, Dec 8, 2014 at 2:50 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > Le 8/12/14 05:43, stepharo a Ã©crit : >> Hi doru >> >> I would like to have playground be named playground and that we >> keep "workspace" but I would like to change the name to >> "SimpleNoteEditor". > Why because this is always good to have simple tools to read from? > (I'm not talking about the current workspace implementation but > the new one). > I would like even try to learn something from Playground > implementation because the tools is more advanced while I'm not > afraid to learn > from a simple tool. > >> I do not like the idea that we are all forced to use one single >> tools. We are adults. >> >> Stef >> >>> Hi, >>> >>> As you might see, the GTPlayground is called playground not >>> workspace. The main reason for this is that workspace implies >>> the place where work is done, and work is typically associated >>> with creating code. >>> >>> This is not the intention of the workspace. >>> >>> Workspace also comes with a history that is associated with >>> actual implementations. While the current GTPlayground might >>> appear to be similar to the workspace, I think the way you can >>> use the latter produces a significant shift. >>> >>> Furthermore, I think the term playground is more inline with the >>> idea of "playing with live objects". And, in the future, the >>> implementation will likely evolve towards even more liveliness. >>> >>> It is for this reason that I would prefer that the World menu >>> item gets renamed to Playground. >>> >>> What do you think? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> >>> "Every thing has its own flow" >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Dec. 10, 2014

Re: [Pharo-dev] Excel binding

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Yes, including this, but not limited to this. I.e. not only generation, but also reading. Generation is just somewhat simpler - so I started from this point. I announced it some tim ago, it's http://ss3.gemstone.com/ss/Tabular.html 2014-12-09 20:49 GMT+03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > El Tue Dec 09 2014 at 2:22:32 PM, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> > escribiÃ³: > >> I'm working on XLSX / ODS support code just now. >> Nothing done on *reading* the data yet, but it may be easily switched. >> >> But my plans do not includes support of (binary) XLS format. >> >> > > Are you working on OpenXML (.xlsx) file generation? > > Regards! >

Dec. 10, 2014

Re: [Pharo-dev] Does Monticello try to install shared pools before methods using them?

by Craig Latta

> What did you have to do to #scanFor:, some kind of proxy detection or > something? Yup, a different hashing scheme for proxies. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Dec. 10, 2014

picture from the whole Pharo

by Alexandre Bergel

Hi! Just to share some pictures that took many many hours to compute: Many more on: https://www.facebook.com/ObjectProfile/posts/744883802264886 <https://www.facebook.com/ObjectProfile/posts/744883802264886> Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 9, 2014

Re: [Pharo-dev] [squeak-dev] re: Does Monticello try to install shared pools before methods using them?

by Eliot Miranda

On Tue, Dec 9, 2014 at 12:36 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > On Tue, Dec 9, 2014 at 8:02 AM, Craig Latta <craig(a)netjam.org> wrote: > > > >> Do your pool references end up being valid? > > > > Aha, the answer is no. So, I had to put some things in a separate > > package which must be loaded first. Among those things is a change > > required by a remote-object-aware version of > > IdentityDictionary>>scanFor:; the system was crashing when they were > > loaded in the wrong order. > > Interesting. What did you have to do to #scanFor:, some kind of proxy > detection or something? > > PS -- I agree with Eliot that MC _should_ handle compiling subclasses > of SharedPool first. I thought it did.. > No, right now only methodAdditions are handled first. Look at MCPackageLoader>>basicLoad which is aching to be refactored to pull the exception handlers out. It should look like basicLoad "Load the contents of some package. This is the core loading method in Monticello. Be wary about modifying it unless you understand the details and dependencies of the various entities being modified." RecentMessages default suspendWhile: [[CurrentReadOnlySourceFiles cacheDuring: [[self innerBasicLoad] on: InMidstOfFileinNotification do: [:n | n resume: true]]] ensure: [self flushChangesFile]] innerBasicLoad "Load the contents of some package. This is the core loading method in Monticello. Be wary about modifying it unless you understand the details and dependencies of the various entities being modified." | pkgName | errorDefinitions := OrderedCollection new. "Obviously this isn't the package name but we don't have anything else to use here. ChangeSet current name will generally work since a CS is usually installed prior to installation." pkgName := ChangeSet current name. preamble ifNotNil: [ChangeSet current preambleString: (self preambleAsCommentNamed: pkgName)]. "Pass 1: Load everything but the methods, which are collected in methodAdditions." additions do: [:ea | ea isMethodDefinition ifTrue: [methodAdditions add: ea asMethodAddition] ifFalse: [[ea load] on: Error do: [errorDefinitions add: ea]]] displayingProgress: 'Reshaping ', pkgName. "Try again any delayed definitions" self shouldWarnAboutErrors ifTrue: [self warnAboutErrors]. errorDefinitions do: [:ea | ea load] displayingProgress: 'Reloading ', pkgName. "Pass 2: We compile new / changed methods" methodAdditions do: [:ea| ea createCompiledMethod] displayingProgress: 'Compiling ', pkgName. 'Installing ', pkgName displayProgressFrom: 0 to: 2 during: [:bar| "There is no progress *during* installation since a progress bar update will redraw the world and potentially call methods that we're just trying to install." bar value: 1. "Pass 3: Install the new / changed methods (this is a separate pass to allow compiler changes to be loaded)" methodAdditions do: [:ea| ea installMethod]. "Pass 4: Remove the obsolete methods" removals do: [:ea| ea unload]]. "Finally, notify observers for the method additions" methodAdditions do: [:each | each notifyObservers] "the message is fake but actually telling people how much time we spend in the notifications is embarrassing so lie instead" displayingProgress: 'Installing ', pkgName. additions do: [:ea | ea postloadOver: (self obsoletionFor: ea)] displayingProgress: 'Initializing ', pkgName But I have to say that I don't understand how basicLoad/innerBasicLoad sorts things. Confusing. Anyway, looks like the "Pass 1: Load everything but the methods, which are collected in methodAdditions." pass needs to be split into something that loads things that inherit from SharedPool first. -- best, Eliot

Dec. 9, 2014

Re: [Pharo-dev] [squeak-dev] re: Does Monticello try to install shared pools before methods using them?

by Chris Muller

On Tue, Dec 9, 2014 at 8:02 AM, Craig Latta <craig(a)netjam.org> wrote: > >> Do your pool references end up being valid? > > Aha, the answer is no. So, I had to put some things in a separate > package which must be loaded first. Among those things is a change > required by a remote-object-aware version of > IdentityDictionary>>scanFor:; the system was crashing when they were > loaded in the wrong order. Interesting. What did you have to do to #scanFor:, some kind of proxy detection or something? PS -- I agree with Eliot that MC _should_ handle compiling subclasses of SharedPool first. I thought it did..

Dec. 9, 2014