- Pharo-dev - lists.pharo.org

Re: [Pharo-project] New Text Completion suggestions

by StÃ©phane Ducasse

Camillo the system should be like that - user can define to use a map vim emacs customizable + pharo for Pharo we need to have a good default. To me the remarks of henrik make sense: the pop up should not stay using arrows should not pop up something on the left of the screen after I really understand that enter is not suited for completion just because of the simple scenario that doru mentioned. but if people cannot leave with enter why not having an option Stef

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by Esteban Lorenzano

On Aug 24, 2012, at 10:05 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote: > >> So you're saying modifiable keyboard shortcuts are a bad design? > > not necessarily but I prefer to have a good default :) so that I do not have to do it. +1 for configurations +1 for a good default > > Stef > >

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by StÃ©phane Ducasse

On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote: > So you're saying modifiable keyboard shortcuts are a bad design? not necessarily but I prefer to have a good default :) so that I do not have to do it. Stef

Aug. 24, 2012

[Pharo-project] GSoC - Package management with Fuel

by Martin Dias

Hi This week has ended Google Summer of Code program 2012. I have to thank Marcus and Carlos Ferro, my mentors, as well as Mariano, Guille Polito, Camillo Bruni, and others, who collaborated in different ways during these three months. Also thank, of course, to Carla and Janko... and Google ;) The main purpose of this mail is to summarize the work done for my project, named "Package management with Fuel" [1][2]. Tools for managing code in Pharo export classes, traits, and methods as series of source definitions, which then import by evaluating them with the compiler. This is basically how FileOut/FileIn or Monticello works. This is slow on large pieces of code, so if you want to install a big package, you need a lot of time compiling it. Why should you compile it again, given that it was all compiled when you exported the package? The bytecodes will be the same again, you know... If you just could load the Classes and Compiled Methods instead of compiling it all again, you can save time. With this goal in mind, I started working in FuelPackageLoader[4] (now Tanker[3]), a prototype we wrote last year, which already exports and imports packages without using any compiler. But it has two important issues: it wasn't capable of export source code, and it wasn't able to tolerate class-shape changes in hierarchies (ie, a change on inst vars in a external superclass). So, we decided to start from scratch with a new prototype, code name Carbono. The idea was to reify how FileOut and FileIn are done, but storing binary information so that compilation can be avoided. In a nutshell, Carbono stores a package into two files: - A sources file, imitating the traditional FileOut chunk format. - A binary file, where uses Fuel[5] to serialize a series of code definitions. Each of them knows the position in the sources file where its source code counterpart is. For example, a class definition knows the position of its comment (in the case it exists), and a method definition knows the position of its source code. A basic example, to export a couple of classes: TAExport new binariesOn: aBinaryStream sourcesOn: aTextStream; behaviors: {ClassA. ClassB}; methods: {}; initializeClasses: true; run. which then you can import with: TAImport new binariesFrom: aBinaryStream sourcesFrom: aTextStream; run. Anyway, you can also choose to: - export only binaries or only sources - import only binaries (source code can be decompiled) - import only sources (via #fileIn) Mariano Martinez Peck worked a lot on it, fixing bugs, and especially optimizing it A LOT, so I hope you will enjoy his demonstration this Monday on ESUG Innovation Awards. Seems that he could export Seaside, Pier and Magritte, and import them in another image, with source code, and just in a few seconds ;) Also, some ultra confidential WikiLeaks revealed that he could export almost all Pharo packages, and import them in a kernel image, all with source codes but without using the compiler :) Note1: Tolerating class-shape changes in hierarchies is not yet done, but it should in some days. So far, the only strategy when a change is detected will be to recompile methods, but it may be more sophisticated in a not-so-far future. Note2: Although finally it was not strictly necessary, Guillermo Polito and me wrote tests for a new ClassBuilder. It is part of Slot, a kind of reification of objects layout made by Toon Verwaest and Camillo Bruni. It is too long to explain it here, but the thing is that was not an easy job, and we hope it will be integrated in Pharo. This is a work in progress, but you can install and try it on latest Pharo 2.0, evaluating: Gofer it squeaksource3: 'PharoTaskForces'; package: 'Slot'; package: 'SlotTests'; load. (Smalltalk at: #SlotVirus) perform: #spread. Gofer it squeaksource3: 'PharoTaskForces'; package: 'SlotsClassBuilderIntegration'; load. Gofer new smalltalkhubUser: 'marianopeck' project: 'Tanker'; package: 'ConfigurationOfTanker'; load. (Smalltalk at: #ConfigurationOfTanker) loadBleedingEdge. Gofer new squeaksource: 'FuelExperiments'; package: 'Carbono'; package: 'CarbonoTests'; load. Cheers, MartÃn [1]: http://gsoc2012.esug.org/projects/fuel-packages [2]: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/tin… [3]: http://marianopeck.wordpress.com/2012/08/11/tanker-transporting-packages-wi… [4]: http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… [5]: http://rmod.lille.inria.fr/web/pier/software/Fuel

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by dimitris chloupis

I will have to agree. I come from blender the 3d application and up to version 2.49 blender did not allow modfiable shortcuts and if you have used a 3d app you know how crucial shortcuts are . Well I knew a lot of people that did not use blender only because of this. In 2.5 blender developer was clear that realised their mistakes and one of the correction was the addition of modifiable shortcuts. Guess what where the sets of shortcuts first released. 3dstudio max and maya, obviously because most people have been coming from those applications. Frankly I dont trust an application or its developers to tell me what is a good shortcut for me. Oh by the way I come from emacs, and emacs shortcuts suck big time :D ... still I love emacs but I would not use it if it did not allow me to modify those shortcuts.And as you might guessed I did not use Blender before 2.5 for the same reason.Â Having a standard set of shortcuts is the easy way for documentation and tutorials, but generally speeking the first thing a user tends to customise in application is the shortcuts. Because people have diffirent needs and use diffirent parts of application.Â ________________________________ From: Camillo Bruni <camillobruni(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Friday, 24 August 2012, 1:37 Subject: Re: [Pharo-project] New Text Completion suggestions On 2012-08-23, at 19:50, Stephan Eggermont <stephan(a)stack.nl> wrote: > Camillo wrote: >> So you're saying modifiable keyboard shortcuts are a bad design? > > Yes. > > That is to say, using them outside of developing a good set of > key bindings (possibly for each language/keyboard). We need them > to get to this consistent set. Options could be on the level of > vi/wordstar/emacs style. I see 3 versions here, I add vim, BOOM flamewar :D. so no options, is no option, forget it... whenever there will be an emacs keybinding set, I will bribe people until I have a corresponding vim set :D

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by Igor Stasenko

On 24 August 2012 02:25, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote: >> On 24 August 2012 01:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> (a bit orthogonal) >> >> i don't understand why we cannot have own, consistent set which is good >> >> for us? >> >> vim, emacs.. >> > >> > >> > better use sets which are already extremely familiar than invent yet another >> > set. to those of us who use these editors (and we are legion) these sets >> > have long become almost subconscious to use. >> > >> >> i know that.. i also came to squeak from outside.. >> but as we say in Ukraine: don't enter others sanctuary with own >> code(set of rules). >> >> >> why this is so important ? Those editors were not written for editing >> >> smalltalk code in mind.. >> >> they are best suited for big, hundreds lines of code, files.. >> > >> > >> > they're the two most popular editors of their type. lots of people use them >> > for other languages without IDE support. They provide convenient power >> > features such as pattern replacement. Not often I find myself filing out >> > Smalltalk code and editing it with vim (sadly I've never learned emacs). >> > >> me too.. i never learned emacs. So, maybe i am completely ignorant and can't see >> why it is so important to have it there.. But then, i don't >> understand, why most of editors i know >> never had emacs/vim key bindings as option? Are they completely stupid? Huh? > > Typing is like playing a musical instrument. A good typist does not look > at the keyboard, and is not consciously aware of the individual keys and > motions of his or her fingers. Once you learn to play a musical instrument, > the mind goes beyond the mechanical motions, and your thoughts and creativity > occur without conscious awareness of fingering positions. A pianist is not > "better than" a banjo player, and a saxophone is not better than a guitar. > I know very well what you talking about. But to me it feels like people asking to add piano keys to saxophone here, because they're good at playing piano. What i would really like is ask the guys who made new shortcuts for nautilus is to spend a bit of extra effort and create a printable shortcuts quick-sheet, so i can print it, stick before my eyes, and don't waste my time digging into menus trying to find what i need each time.. This would speed up learning process a lot. > This is why key bindings are important. Our brains and our fingers just work > that way. If you can play a saxophone and edit in emacs, then you may not be > comfortable communicating with a guitar fretboard or a vi editor. > > Personally, I am a mediocre guitarist and vi user, and sadly I never learned > emacs or piano ;) > >> >> So, you know, if we follow that logic.. hey we don't have a unix command line.. >> so maybe we should add an option: either workspace or command line? >> and then introduce nice terminal emulation with prompt, users and .bashrc .. >> ahh.. what the hell.. lets replicate whole unix environment.. imagine >> how many happy users will join us then! > > Ack! Pfft! What a horrible idea: > http://wiki.squeak.org/squeak/6023 > > ;) > > Dave > > -- Best regards, Igor Stasenko.

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by David T. Lewis

On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote: > On 24 August 2012 01:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >> (a bit orthogonal) > >> i don't understand why we cannot have own, consistent set which is good > >> for us? > >> vim, emacs.. > > > > > > better use sets which are already extremely familiar than invent yet another > > set. to those of us who use these editors (and we are legion) these sets > > have long become almost subconscious to use. > > > > i know that.. i also came to squeak from outside.. > but as we say in Ukraine: don't enter others sanctuary with own > code(set of rules). > > >> why this is so important ? Those editors were not written for editing > >> smalltalk code in mind.. > >> they are best suited for big, hundreds lines of code, files.. > > > > > > they're the two most popular editors of their type. lots of people use them > > for other languages without IDE support. They provide convenient power > > features such as pattern replacement. Not often I find myself filing out > > Smalltalk code and editing it with vim (sadly I've never learned emacs). > > > me too.. i never learned emacs. So, maybe i am completely ignorant and can't see > why it is so important to have it there.. But then, i don't > understand, why most of editors i know > never had emacs/vim key bindings as option? Are they completely stupid? Huh? Typing is like playing a musical instrument. A good typist does not look at the keyboard, and is not consciously aware of the individual keys and motions of his or her fingers. Once you learn to play a musical instrument, the mind goes beyond the mechanical motions, and your thoughts and creativity occur without conscious awareness of fingering positions. A pianist is not "better than" a banjo player, and a saxophone is not better than a guitar. This is why key bindings are important. Our brains and our fingers just work that way. If you can play a saxophone and edit in emacs, then you may not be comfortable communicating with a guitar fretboard or a vi editor. Personally, I am a mediocre guitarist and vi user, and sadly I never learned emacs or piano ;) > > So, you know, if we follow that logic.. hey we don't have a unix command line.. > so maybe we should add an option: either workspace or command line? > and then introduce nice terminal emulation with prompt, users and .bashrc .. > ahh.. what the hell.. lets replicate whole unix environment.. imagine > how many happy users will join us then! Ack! Pfft! What a horrible idea: http://wiki.squeak.org/squeak/6023 ;) Dave

Aug. 24, 2012

Re: [Pharo-project] New Text Completion suggestions

by Fernando Olivero

Igor, as usual your true object-oriented thinking helps us see a better path... We need a customized UI interaction for Smalltalk, instead of asking for TEXT editors devised for a different setup. What's missing is a Smalltalk method shape(morph, etc...), highly customized for editing/navigating statements written in the Smalltalk syntax. ( unless you want to code the methods using the workspace.....) We can still preserve cmd-c for copy, and cmd-v for paste...IMO it's not about inventing a new set of keyboard shortcuts, but more about manipulating objects at the right level of abstraction. Saludos, Fernando On Fri, Aug 24, 2012 at 1:40 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 August 2012 01:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> (a bit orthogonal) >>> i don't understand why we cannot have own, consistent set which is good >>> for us? >>> vim, emacs.. >> >> >> better use sets which are already extremely familiar than invent yet another >> set. to those of us who use these editors (and we are legion) these sets >> have long become almost subconscious to use. >> > > i know that.. i also came to squeak from outside.. > but as we say in Ukraine: don't enter others sanctuary with own > code(set of rules). > >>> why this is so important ? Those editors were not written for editing >>> smalltalk code in mind.. >>> they are best suited for big, hundreds lines of code, files.. >> >> >> they're the two most popular editors of their type. lots of people use them >> for other languages without IDE support. They provide convenient power >> features such as pattern replacement. Not often I find myself filing out >> Smalltalk code and editing it with vim (sadly I've never learned emacs). >> > me too.. i never learned emacs. So, maybe i am completely ignorant and can't see > why it is so important to have it there.. But then, i don't > understand, why most of editors i know > never had emacs/vim key bindings as option? Are they completely stupid? Huh? > > So, you know, if we follow that logic.. hey we don't have a unix command line.. > so maybe we should add an option: either workspace or command line? > and then introduce nice terminal emulation with prompt, users and .bashrc .. > ahh.. what the hell.. lets replicate whole unix environment.. imagine > how many happy users will join us then! > > -- > Best regards, > Igor Stasenko. >

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Igor Stasenko

On 24 August 2012 01:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> (a bit orthogonal) >> i don't understand why we cannot have own, consistent set which is good >> for us? >> vim, emacs.. > > > better use sets which are already extremely familiar than invent yet another > set. to those of us who use these editors (and we are legion) these sets > have long become almost subconscious to use. > i know that.. i also came to squeak from outside.. but as we say in Ukraine: don't enter others sanctuary with own code(set of rules). >> why this is so important ? Those editors were not written for editing >> smalltalk code in mind.. >> they are best suited for big, hundreds lines of code, files.. > > > they're the two most popular editors of their type. lots of people use them > for other languages without IDE support. They provide convenient power > features such as pattern replacement. Not often I find myself filing out > Smalltalk code and editing it with vim (sadly I've never learned emacs). > me too.. i never learned emacs. So, maybe i am completely ignorant and can't see why it is so important to have it there.. But then, i don't understand, why most of editors i know never had emacs/vim key bindings as option? Are they completely stupid? Huh? So, you know, if we follow that logic.. hey we don't have a unix command line.. so maybe we should add an option: either workspace or command line? and then introduce nice terminal emulation with prompt, users and .bashrc .. ahh.. what the hell.. lets replicate whole unix environment.. imagine how many happy users will join us then! -- Best regards, Igor Stasenko.

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Eliot Miranda

On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > (a bit orthogonal) > i don't understand why we cannot have own, consistent set which is good > for us? > vim, emacs.. better use sets which are already extremely familiar than invent yet another set. to those of us who use these editors (and we are legion) these sets have long become almost subconscious to use. why this is so important ? Those editors were not written for editing > smalltalk code in mind.. > they are best suited for big, hundreds lines of code, files.. > they're the two most popular editors of their type. lots of people use them for other languages without IDE support. They provide convenient power features such as pattern replacement. Not often I find myself filing out Smalltalk code and editing it with vim (sadly I've never learned emacs). > while something like that in our case is an exception rather than norm. > So, why some people striving for having same keys as there? Just > because they get used to them? > > Seriously vim? A modal editor which is invented for editing files on > obscure terminals, where you don't even have a cursor keys on > keyboard? I pass.. > > Just give me a decent editor with good cursor navigation, selection > and undo/redo/find/replace, that's all i need. > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Aug. 23, 2012