- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Interactive Notebook

by GOUBIER Thierry

Then go for your enhanced workspace :) Making good tools in my experience takes a lot of time, refining details here and there, but it's really worth it because it changes the way you work. I can't relate too much to Emacs, I allways found it a too huge investment (shortcuts, configuration time) for the gain it could bring. Mind you, when I started programming heavily, it was in Smalltalk and Self, so maybe this is why ;) Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de kilon alios [kilon.alios(a)gmail.com] EnvoyÃ© : mardi 15 juillet 2014 22:37 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Well at least for me , the one thing I don't like about Pharo is the "window hell" . Even with window groups , which by the way are a great addition , is easy to get lost and feel uncomfortable. As I said I am inspired by emacs , I like its workflow very much and it will be great if I manage to bring even a small part of the experience to pharo. My goal is not to make something monolithic from the code perspective but offer a unified user experience. I prefer my code as modular as it can be. Emacs after all is extremely modular. At worst I would end up with a slightly more powerful workspace and since workspace is my No1 tool I use to test and try code that is better than nothing :) On Tue, Jul 15, 2014 at 11:25 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: I'm not sure about the replacing everything at once. Good tools doing exactly what they are intended for are great; the ability to switch easily from one tool to another allows for very focused work, where you switch from one task to another, and reduce your cognitive overhead because you don't have to bother with them until you need them. Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de kilon alios [kilon.alios(a)gmail.com<mailto:kilon.alios@gmail.com>] EnvoyÃ© : mardi 15 juillet 2014 20:25 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook I have tried to make something similar with Rubric example of Workspace. My dream is a Super Workspace to replace all IDE tools inside pharo, system browser, Monticello, inspector, debugger , versioner , etc inspired by emacs and of course ipython. I am still working on it from time to time, but its a low priority project for now. I am sure other people have similar goals so I am also interested in joining efforts. Also I am interested in visual coding so I am flirting with Phratch and wonder how Phratch would mix with my Super Workspace concept. There is certainly a lot of potential here. On Tue, Jul 15, 2014 at 9:11 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Demo of what? New GUI, new text editor? Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de stepharo [stepharo(a)free.fr<mailto:stepharo@free.fr>] EnvoyÃ© : mardi 15 juillet 2014 20:00 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Thierry I can tell you that I got a demo made by gary chambers and this is impressive and all done in Pharo. In addition with the new text model, it will really change the situation. Stef On 15/7/14 13:33, Goubier Thierry wrote: > I'm scanning a bit among scientific / computation languages (including > GUIs) and I'd like to know if some work has been done on interactive > notebooks gui concepts? > > I'm thinking of something like: http://ipython.org/notebook.html > > I know that the Pharo text editing capabilities are not up to that > kind of job, but I'd like to know if some would be interested in being > able to interact via that kind of development environment. > > Thierry

July 15, 2014

Re: [Pharo-dev] Interactive Notebook

by kilon alios

Well at least for me , the one thing I don't like about Pharo is the "window hell" . Even with window groups , which by the way are a great addition , is easy to get lost and feel uncomfortable. As I said I am inspired by emacs , I like its workflow very much and it will be great if I manage to bring even a small part of the experience to pharo. My goal is not to make something monolithic from the code perspective but offer a unified user experience. I prefer my code as modular as it can be. Emacs after all is extremely modular. At worst I would end up with a slightly more powerful workspace and since workspace is my No1 tool I use to test and try code that is better than nothing :) On Tue, Jul 15, 2014 at 11:25 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > I'm not sure about the replacing everything at once. Good tools doing > exactly what they are intended for are great; the ability to switch easily > from one tool to another allows for very focused work, where you switch > from one task to another, and reduce your cognitive overhead because you > don't have to bother with them until you need them. > > Thierry > > ------------------------------ > *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de kilon > alios [kilon.alios(a)gmail.com] > *EnvoyÃ© :* mardi 15 juillet 2014 20:25 > > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Interactive Notebook > > I have tried to make something similar with Rubric example of > Workspace. My dream is a Super Workspace to replace all IDE tools inside > pharo, system browser, Monticello, inspector, debugger , versioner , etc > inspired by emacs and of course ipython. > > I am still working on it from time to time, but its a low priority > project for now. I am sure other people have similar goals so I am also > interested in joining efforts. > > Also I am interested in visual coding so I am flirting with Phratch and > wonder how Phratch would mix with my Super Workspace concept. There is > certainly a lot of potential here. > > > > On Tue, Jul 15, 2014 at 9:11 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> > wrote: > >> Demo of what? New GUI, new text editor? >> >> Thierry >> ________________________________________ >> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >> stepharo [stepharo(a)free.fr] >> EnvoyÃ© : mardi 15 juillet 2014 20:00 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Interactive Notebook >> >> Thierry >> >> I can tell you that I got a demo made by gary chambers and this is >> impressive and all done in Pharo. >> In addition with the new text model, it will really change the situation. >> >> Stef >> >> On 15/7/14 13:33, Goubier Thierry wrote: >> > I'm scanning a bit among scientific / computation languages (including >> > GUIs) and I'd like to know if some work has been done on interactive >> > notebooks gui concepts? >> > >> > I'm thinking of something like: http://ipython.org/notebook.html >> > >> > I know that the Pharo text editing capabilities are not up to that >> > kind of job, but I'd like to know if some would be interested in being >> > able to interact via that kind of development environment. >> > >> > Thierry >> >> >> >> >

July 15, 2014

Re: [Pharo-dev] Interactive Notebook

by GOUBIER Thierry

Hi Doru, I'd be interested, yes, especially if there is a way to hook or build IDEs for other languages / DSLs. And the underlying abstraction which would allow one to understand and manipulate how the stacked environments are linked to each other. Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Tudor Girba [tudor(a)tudorgirba.com] EnvoyÃ© : mardi 15 juillet 2014 22:20 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Hi, Indeed, this is where we want to go with the GTPlayground next :). The idea is to have multiple segments that can be previewed and that are stacked on one another. Modifying an upper segment leads to reevaluating the lower ones. @Thierry: would you like to join efforts? Cheers, Doru On Tue, Jul 15, 2014 at 2:15 PM, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Le 15/07/2014 14:05, Ben Coman a Ã©crit : Goubier Thierry wrote: I'm scanning a bit among scientific / computation languages (including GUIs) and I'd like to know if some work has been done on interactive notebooks gui concepts? I'm thinking of something like: http://ipython.org/notebook.html I know that the Pharo text editing capabilities are not up to that kind of job, but I'd like to know if some would be interested in being able to interact via that kind of development environment. Thierry I'd be very interested in that kind of feature. I'd imagine you have a number of separate text areas in one workspace that are evaluated in order of their origin. Yes, it seems to be the case in the example I was looking at. Sort of the recording of an interactive session with a terminal. Would be interesting to see if we can go back and edit. Only sad thing I see in the way it is presented: output is not part of the program. I recommend you take MathCAD for a test drive. http://www.ptc.com/product/mathcad/ I'll have a look, thanks! cheers, Ben -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92<tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow"

July 15, 2014

Re: [Pharo-dev] Interactive Notebook

by GOUBIER Thierry

No worries. What I wrote in VW 20 years ago is not available anymore either ;) But it could have been used to build a interactive notebook :( Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] EnvoyÃ© : mardi 15 juillet 2014 22:10 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook 2014-07-15 17:34 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>>: I've never seen that in VW. But your feedback is interesting; maybe there is something to look at. No, sorry for misunderstanding, it was closed source developments in VW...

July 15, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Nicolas Cellier

2014-07-15 20:27 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > I find the "... it" suffix obsolete. "Delete it", "Do it", "Print it", etc. > > Maybe it made sense in the past, but today it feels weird. > > There is no "Cut it", "Paste it", etc... nor similar in other software. > IMO, if the menu is contextual, the context already applies the "it" > (subject). > > Regards. > > Did you notice "it" is only mentionned when you will evaluate (do it / print it / debug it / ... )? Otherwise, if it's just text editing there is no it. So there is a sort of logic. IMO that makes sense, because evaluating is a special action. > > > > > Esteban A. Maringolo > > > 2014-07-15 15:16 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > > In python there is eval() which evaluates > > > > and there is exec() which executes > > > > The difference is that one calculates a value which it returns , the > other > > executes code. > > > > Personally I find "do it" very good choice because it makes clear what > you > > referring to , in contrast "evaluate" and "execute" can mean different > > things under different context. > > > > > +1 > > On Tue, Jul 15, 2014 at 9:07 PM, stepharo <stepharo(a)free.fr> wrote: > >> > >> In general I banned evaluate from the book vocabulary because people > think > >> that this is slower. > Compiler evaluate: is more how you do it ;) I'd say just do it (it's ok, we are an imperative language after all). > >> I saw teachers writing that smalltalk is interpreted and java compiled > :). > >> I use execute. > >> > >> > Ah, Cursor execute showWhile: [...], st80-v2 also had this vocabulary. So if the UI must reflect that you execute something, it's certainly a valuable word. I checked, it's still in Pharo 3.0 :) Personally, I find it too unpersonnal though. A robot, or an automaton executes a list of instructions. I prefer the anthropo-morphic programming ;) >> > >> On 15/7/14 19:20, Ben Coman wrote: > >>> > >>> > >>> Mostly I take for granted that "DoIt" has always been the way to > evaluate > >>> things with Smalltalk, however I find it awkward to use in writing a > >>> tutorial. Some examples... * After saving, select "Grid new" and > "DoIt" -- > >>> this sounds awkward, and even that you might need select the latter as > well. > >>> * After saving, "Grid new" DoIt. -- doesn't read nice > >>> * After saving, DoIt to "Grid new." -- worst of all > >>> > >>> I'd feel better writing something like this... > >>> * After saving, evaluate "Grid new". > >>> but "evaluate" is not an item in the menus. I think actually many > people > >>> talk this way with the implicit convention that "evaluate" means > "DoIt". > >>> > >>> So first, does anyone have a good way to compose sentences using > "DoIt". > >>> Second, how evil would it be to change the menus from "DoIt" to > >>> "Evaluate" and so avoid the implicit convention. > >>> > >>> cheers -ben > >>> > >>> > >>> > >>> > >> > >> > > > >

July 15, 2014

Re: [Pharo-dev] Interactive Notebook

by GOUBIER Thierry

I'm not sure about the replacing everything at once. Good tools doing exactly what they are intended for are great; the ability to switch easily from one tool to another allows for very focused work, where you switch from one task to another, and reduce your cognitive overhead because you don't have to bother with them until you need them. Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de kilon alios [kilon.alios(a)gmail.com] EnvoyÃ© : mardi 15 juillet 2014 20:25 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook I have tried to make something similar with Rubric example of Workspace. My dream is a Super Workspace to replace all IDE tools inside pharo, system browser, Monticello, inspector, debugger , versioner , etc inspired by emacs and of course ipython. I am still working on it from time to time, but its a low priority project for now. I am sure other people have similar goals so I am also interested in joining efforts. Also I am interested in visual coding so I am flirting with Phratch and wonder how Phratch would mix with my Super Workspace concept. There is certainly a lot of potential here. On Tue, Jul 15, 2014 at 9:11 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Demo of what? New GUI, new text editor? Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de stepharo [stepharo(a)free.fr<mailto:stepharo@free.fr>] EnvoyÃ© : mardi 15 juillet 2014 20:00 Ã : Pharo Development List Objet : Re: [Pharo-dev] Interactive Notebook Thierry I can tell you that I got a demo made by gary chambers and this is impressive and all done in Pharo. In addition with the new text model, it will really change the situation. Stef On 15/7/14 13:33, Goubier Thierry wrote: > I'm scanning a bit among scientific / computation languages (including > GUIs) and I'd like to know if some work has been done on interactive > notebooks gui concepts? > > I'm thinking of something like: http://ipython.org/notebook.html > > I know that the Pharo text editing capabilities are not up to that > kind of job, but I'd like to know if some would be interested in being > able to interact via that kind of development environment. > > Thierry

July 15, 2014

Re: [Pharo-dev] Interactive Notebook

by Tudor Girba

Hi, Indeed, this is where we want to go with the GTPlayground next :). The idea is to have multiple segments that can be previewed and that are stacked on one another. Modifying an upper segment leads to reevaluating the lower ones. @Thierry: would you like to join efforts? Cheers, Doru On Tue, Jul 15, 2014 at 2:15 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 15/07/2014 14:05, Ben Coman a Ã©crit : > > Goubier Thierry wrote: >> >>> I'm scanning a bit among scientific / computation languages (including >>> GUIs) and I'd like to know if some work has been done on interactive >>> notebooks gui concepts? >>> >>> I'm thinking of something like: http://ipython.org/notebook.html >>> >>> I know that the Pharo text editing capabilities are not up to that >>> kind of job, but I'd like to know if some would be interested in being >>> able to interact via that kind of development environment. >>> >>> Thierry >>> >> I'd be very interested in that kind of feature. I'd imagine you have a >> number of separate text areas in one workspace that are evaluated in >> order of their origin. >> > > Yes, it seems to be the case in the example I was looking at. Sort of the > recording of an interactive session with a terminal. > > Would be interesting to see if we can go back and edit. > > Only sad thing I see in the way it is presented: output is not part of the > program. > > > I recommend you take MathCAD for a test drive. >> http://www.ptc.com/product/mathcad/ >> > > I'll have a look, thanks! > > cheers, Ben >> >> >> >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- www.tudorgirba.com "Every thing has its own flow"

July 15, 2014

Re: [Pharo-dev] Interactive Notebook

by Nicolas Cellier

2014-07-15 17:34 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr>: > I've never seen that in VW. But your feedback is interesting; maybe there > is something to look at. > > No, sorry for misunderstanding, it was closed source developments in VW... > I wonder if looking at some of the GTPlayground stuff with another angle > could be interesting (i.e. page approach) or simply study what could be > done if we could capture a task by embedding morphs inside the text. > > I feel like the notebook concept in itself is poor in that you have to > interact with the program objects via the command line (i.e. the language > console; be it R or Python, or Mathlab) and that is certainly inferior to > the ability to select and run anywhere, inspect, explore, playground stuff. > > Le 15/07/2014 17:21, Nicolas Cellier a Ã©crit : > > We had this kind of workbook 20 years ago in VW with mathematical >> formulae and graphics (plot) embedded. >> What we did was to avoid continous scrolling of the whole document, but >> rather have the plan of the document on the left pane of the notebook >> (just an indented tree like word navigation mode), and the text on the >> right pane for only the currently selected chapter (in a way, it's a lot >> like the source code browser). This way, no need to compose very large >> Text in Smalltalk (I also doubt our editors really scale). >> Then we could output a static view in PostScript or LaTeX. >> >> The greatest limitation IMO was not really the UI, but the principle of >> the Notebook itself: we soon needed to access the results of previous >> chunks of code, and we implemented this with an environment (understand >> some global variables). >> From software quality POV, working with such global vars is very >> disappointing and does not really scale either. >> >> The second limitation of the workbook is that, while it's very good for >> small projects (like maybe we can have in school), it's not the right >> tool for producing documents with a synthesis of the results, which >> remain the main added value of humans, so which was what we were asked >> for. >> >> However I'm still curious how far we can go with those notebooks, >> because the idea is seducing. Maybe it was our own usage which was bad... >> > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

July 15, 2014

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3041/. The principal changes are fixing a performance regression in the 3040 VMs, fixing some Spur bugs in primitiveClone/shallowCopy, and radically simplifying the Spur become implementation, trading the elimination of lots of post-become class table scanning for adding read barriers to class hierarchy method lookup. CogVM source as per VMMaker.oscog-eem.820/r3041 Put the handling of the cloning of cogged methods in the clone: implementations, removing it from the primitive. Add it to the pinning clone too. Specialize the store check trampoline generation. Move it down to the relevant object representations. Move setting of isRemembered flag to true into SpurGenerationScavenger>> remember:. Inline possibleRootStoreInto: (given that remember: is /not/ inlined. Call remember directly from the ceStoreCheckTrampoline, and hence have remember: answer its argument. Fix localization bug. Variables in initialize methods were not considered references (cuz there are excluded). This caused VMMaker.oscog-eem.816's extraction of zero/false vars to StackInterpreter>>#initialize to cause nextPollUsecs to be localized to checkForEventsMayContextSwitch:. Spur: Fix bug in scanClassPostBecome:effects: with new lazy selector following policy by... throwing it all away. The read barriers on method lookup (of the methodClass association in super sends, of the superclass link, of method dictionaries, method dictionary arrays, selectors and methods is cheap. So replace scanning classes and method dictionaries in the class table post become with read marriewrs on methodClass, superclass and method dictionary etc on lookup. The read barrier on an object from which we are going to fetch state (such as a class or method dictionary) is essentially free on modern machines because the class index and the state very likely share a cache line, and the register code for testing is so cheap compared to memory access. Further the read barrier on selectors is cheap because the method lookup cache is effective in reducing the number of message lookups and because nil entries need no check. So nuke all the followNecessaryForwardingInMethod: machinery including the cmUsesMethodClass hack. Nuke scanClassPostBecome:effects:. Rip out the forwardingCount: measurement code. It causes bad performance regressions (due to failing inlines?) Clean up, e.g. replace followNonImmediateField:ofObject: uses with followObjField:ofObject:. canPinObjects can be inlined. -- best, Eliot

July 15, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40087 Home: https://github.com/pharo-project/pharo-core

July 15, 2014