[Pharo-project] Spreading the word about Pharo
Do you think it is time to ask maintainers of pages about Smalltalk, like http://www.engin.umd.umich.edu/CIS/course.des/cis400/smalltalk/smalltalk.html to include Pharo be it as an entry or at least a link? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] accessors entry in submenu of refactor class menu (OB package Browser)
Is it by design decision: That we don't have a way to create accessor (specifically the getters) that do lazy evaluation? The way the tool works now is that if one clicks refactor->accessors you get a new window with all accessors "created" and you have to delete the ones you don't want? And last but not least, if I attempt to edit a method in the new window "Changes: refactor class, accessors" I get an MNU: OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass. -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] No replace menu entry in the tools of Pharo image?
Am I the only soul that misses the replace entry which I would expect to be near the 'find' and 'find again' entries? We have even an entry 'set search string' but not a replace one! -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] accessors entry in submenu of refactor class menu (OB package Browser)
Em 12/11/2009 19:08, Lukas Renggli escreveu: > > That we don't have a way to create accessor (specifically the > > getters) that do lazy evaluation? > Lazy initialization? What do you want to do? SomeClass>>aVariable aVariable isNil ifTrue: [aVariable := "sensible thing to do"]. ^aVariable Most of the cases you will have the creation of an object or have the variable set to zero in the block. > > The way the tool works now is that if one clicks > > refactor->accessors you get a new window with all accessors > > "created" and you have to delete the ones you don't want? > You can disable the preference #promptOnRefactoring to not display > the changes and perform the refactoring immediately. This is the opposite I'm searching! > > And last but not least, if I attempt to edit a method in the new > > window "Changes: refactor class, accessors" I get an MNU: > > OR2AddMethodChangeNode(Object)>>doesNotUnderstand: #selectedClass. > I cannot reproduce the problem in the standard OmniBrowser. I > commonly edit the changes before applying the refactorings. This is happening in an image: Pharo1.0rc1 Latest update: #10495 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] No replace menu entry in the tools of Pharo image?
Em 12/11/2009 19:47, Adrian Lienhard escreveu: > Hi Cesar > I don't miss it. How does it work? When you select 'replace' instead of 'find' you get a window with _two_ entry fields one for the string you want to replace and another for the replacement (OK I concede I'm used to VW ;-) > I also wonder where you found the menu item 'set search string'? If you click the yellow button in the OB Package Browser in the source pane you'll find it (Pharo1.0rc1 Latest update: #10495). > If there is enough interest from other people we can add the > replace. But we should take care not to get long menus > again. Thinking about it, I would remove 'find again (g)' from the > context menu. Or does anybody use it from the menu, rather than with > the keyboard shortcut? You made an interesting point: for experienced people (who already learned the keyboard shorcuts) probably the menus are less useful, but for newcomers or less frequent coders, the menus are the way to remember the functionality available. So I think if we want to remove too many items from the menus we have to put back a workspace filled with an introductory document which among other things has the list of keyboard shortcuts. Better even would be to have an updated quick reference card to render in PDF! Regards, -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] accessors entry in submenu of refactor class menu (OB package Browser)
Em 12/11/2009 19:29, Lukas Renggli escreveu: > >> > That we don't have a way to create accessor (specifically the > >> > getters) that do lazy evaluation? > >> Lazy initialization? What do you want to do? > > SomeClass>>aVariable > > aVariable isNil ifTrue: [aVariable := "sensible thing to do"]. > >^aVariable > How would the refactoring engine figure out what you want to do? We just give it some hints. To have an example of this functionality pls get a look at the page nine of http://cormas.cirad.fr/forum/cormas/old2004_2006/att-0518/01-IntroCormas_Elections.pdf > Normally you just change the code directly in the changes browser. > I see, was my plan B, but I'm experiencing the bug I describe... > >> > And last but not least, if I attempt to edit a method in the > >> > new window "Changes: refactor class, accessors" I get an MNU: > >> > OR2AddMethodChangeNode(Object)>>doesNotUnderstand: > >> > #selectedClass. > >> I cannot reproduce the problem in the standard OmniBrowser. I > >> commonly edit the changes before applying the refactorings. > > This is happening in an image: Pharo1.0rc1 Latest update: #10495 > Looks like a bug in OCompletion. > I am still using ECompletion, so I've not seen that bug before. OK. This begs the question: which of the completions engines is supposed to be the 'official' one? Regards, -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Status about compiler _ changes
Em 13/11/2009 13:36, Lukas Renggli < reng...@gmail.com > escreveu: >> It should be possible to forbid _ assignment in interactive mode, but >> still authorize in batch mode (loading an external package for >> example) to make sure those assignments disappear... > Yes, but you still wouldn't know if a_1 is an old assignment or a new > variable access. Or am I missing something? Lukas, I'm thinking aloud, so bear with me! I think that an "a_1." would be sintatically incorrect except if you can find a variable elsewhere a_1, right? My 0.019... -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Spreading the word about Pharo
Sadly this happens more often with Smalltalk related pages. . . Em 16/11/2009 17:50, Oscar Nierstrasz escreveu: LOL! That web 1.0 page has not been modified since Oct 1999. - on On Nov 12, 2009, at 19:31, Stéphane Ducasse wrote: > yes > > On Nov 12, 2009, at 7:27 PM, csra...@bol.com.br wrote: > >> Do you think it is time to ask maintainers of pages about Smalltalk, like >> http://www.engin.umd.umich.edu/CIS/course.des/cis400/smalltalk/smalltalk.html >> to include Pharo be it as an entry or at least a link? >> >> -- >> Cesar Rabak >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] LaTeX users: favorite editor??
I use Emacs + AUCTeX + RefTeX Em 21/11/2009 17:39, Schwab,Wilhelm K < bsch...@anest.ufl.edu > escreveu: Stef, I looked at the PBE page again and noticed a link to the LaTeX sources for the book, which lead me to wonder what editor you use? I recently found TeX Maker, and generally like it. My one complaint is that (so far at least) I have found no analog to texify, which (part of MikTeX) would do everything required to update a document. While that might be painful for "quick" edits to a book, it's great for shorter documents or to ensure that the toc, references, etc. are up to date. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo by Example - chapter about Exception - Error - Notification - Abort?
I started reading it. It seems to me that at page 5 the last paragraph "If Smalltalk did provide exception-handling support, then the tiny example we saw in the previous section would be written something like this," is missing a negative like «"If Smalltalk did *not* provide exception-handling support..."». Isn't it? -- Cesar Rabak Em 23/11/2009 16:57, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: > Enjoy I had a lot of fun writing it when my family went to the swimming pool > and I could > concentrate :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (no subject)
Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs? I wonder where are they 20 years ahead?! Em 24/11/2009 15:08, Damien Cassou escreveu: On Mon, Nov 23, 2009 at 7:53 PM, Stéphane Ducasse wrote: >> I know the refactoring engine of Eclipse. It must be 20 years ahead of >> Smalltalk. > > Not sure because it is full of bugs because Java is complex. I use Eclipse and its refactorings everyday. They work quite well. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (no subject)
OK, So it is the 'ergonomics' of the tool that makes you feel it is years ahead... Usability is a very difficult thing to measure and/or evaluate. Regards, -- Cesar Rabak Em 24/11/2009 15:55, Lukas Renggli escreveu: > Is there a kind of comparison table of the features available in Eclipse > versus the Smalltalks' RBs? I was not talking about feature completeness, I was more talking about the usability of the editor and how the different tools integrate. It is impressive that you see the renaming happening live in Eclipse while you type a new class/variable/method name. I don't know of a single refactoring in Eclipse that is not available in Smalltalk, of course excluding some of the refactorings that mangle with types, packages or inner-class and that do not make sense in the context of Smalltalk. Furthermore the Smalltalk refactoring engine provides an universal code transformation engine that allows one to script new transformations (refactorings) within seconds. This is something that I have not yet seen in any other language with that sophistication. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Re: c.l.s "Pharo less responsive than Squeak?"
Do you also see as these persons report it? http://groups.google.com.br/group/comp.lang.smalltalk/browse_thread/thread/9f38eaa2a9c29213 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] c.l.s "Pharo less responsive than Squeak?"
Stef, Beware Guido's report if for a Windows machine ;-) Em 26/11/2009 19:00, Stéphane Ducasse escreveu: good to let us know. I do not see pharo getting up to 130 Mb. On Nov 26, 2009, at 9:53 PM, csra...@bol.com.br wrote: > > Do you also see as these persons report it? > > http://groups.google.com.br/group/comp.lang.smalltalk/browse_thread/thread/9f38eaa2a9c29213 > > -- > Cesar Rabak > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: about Pharo
Folks, If we can devise a "benchmark" kind of package I have an old P-III with OEM Win2K that I can put for comparing against my (newer, but not leading edge) machines. Em 26/11/2009 19:45, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Begin forwarded message: > From: neil butterworth > Date: November 26, 2009 10:29:57 PM GMT+01:00 > To: Stéphane Ducasse > Subject: Re: about Pharo > > On Thu, Nov 26, 2009 at 9:04 PM, Stéphane Ducasse > wrote: >> Hi Neil > > Hello > >> >> what you report is strange. >> Can you let us know: > >>- vm > > The Pharo VM is the current (as of a couple of days ago) download from > the Pharo Homepage - Squeak 3.11.4 (beta). > >>- OS > > Win2K SP4 > >>- image version > > Once again, a very recent download - pharo1.0-10493-rc1dev09.11.2.image > >>- your display depth > > True Color 24 bit > >> Because people are using pharo on production and we got an increase of 15% >> of Morphic >> in pharo 1.1 so I have some doubts. > > It is very definitely much slower than Squeak on my system. This is an > old laptop 900MHz P3, but it has no problems at all running Squeak. > > Neil Butterworth ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about Pharo
Yep, I think we should create a benchmark _image_ then... Em 26/11/2009 20:02, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Thanks for your reply :) >> what you report is strange. >> Can you let us know: > >>- vm > > The Pharo VM is the current (as of a couple of days ago) download from > the Pharo Homepage - Squeak 3.11.4 (beta). > >>- OS > > Win2K SP4 > >>- image version > > Once again, a very recent download - pharo1.0-10493-rc1dev09.11.2.image > >>- your display depth > > True Color 24 bit I have Display depth -> 32 then 24 looks strange to me. depth: bitsPerPixel (bitsPerPixel > 32 or: [(bitsPerPixel bitAnd: bitsPerPixel-1) ~= 0]) ifTrue: [self halt: 'bitsPerPixel must be 1, 2, 4, 8, 16 or 32']. depth := bitsPerPixel Can you type Display depth and Display depth: 32 to see if this change something? >> Because people are using pharo on production and we got an increase of 15% >> of Morphic >> in pharo 1.1 so I have some doubts. > > It is very definitely much slower than Squeak on my system. This is an > old laptop 900MHz P3, but it has no problems at all running Squeak. We should keep an old machine around to test it. this is strange. Because the Ob2Browser is slow because it displays package and getting package information is slow. Which browser are you using Can you give a try to change it and use the system browser (to change click on the right icon on the window ... Choose new default menu) Can you change the theme? using the preference pane? Thanks Stef > > Neil Butterworth ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Method versioning in Pharo images
I would like to know if the past history of the method's versions has been lost by design or accident. In the core image for example it is possible only for the method Object>>at: an entry "yo 6/29/2004 11:39". Are we considering the implementation of Pharo as a clean slate and we'll start from some epoch date? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Method versioning in Pharo images
Em 28/11/2009 21:19, Marcus Denker < den...@acm.org > escreveu: > On Nov 28, 2009, at 9:42 PM, csra...@bol.com.br wrote: > > > I would like to know if the past history of the method's versions > >has been lost by design or accident. > > In the core image for example it is possible only for the method > > Object>>at: an entry "yo 6/29/2004 11:39". > > Are we considering the implementation of Pharo as a clean slate > > and we'll start from some epoch date? > We had to make new .sources for 1.0... and even if not: the problem > is that the .changes can only be 32MB, and that is reached fast. In > 3.9, we even had to condense changes in the middle of the release > cycle. (This is what you get from never moving on from outdated > technology) I see. Then is an enviromental imposition ;-) > What I would want to have is a server with all old code that than > is queried by the image... Marcus, let me ask to put in this wish list we could have then a versioning system similar to RCS/CVS and family where you name (in fact you number and give then alias names, but I digress. . .) the versions and can put comments documenting the code changes for the non obvious things in code. An escape hatch for the .changes limit would be to serialize all the versioning information in a .versions file. -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [BUG]UndefinedObject(Object)>>doesNotUnderstand: #
I got a recent dev-image and ran some tests (all CollectionTests if this
matter) and attempted to store the result.
30 November 2009 5:26:40 pm
VM: Win32 - IX86 - NT - Squeak3.10.2 of '5 June 2008' [latest update: #7179]
Image: PharoCore1.0rc1 [Latest update: #10498]
SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir E:\Pharo
Trusted Dir E:\Pharo\Cesar S. Rabak
Untrusted Dir C:\Documents and Settings\Cesar S. Rabak\Meus documentos\My Squeak
UndefinedObject(Object)>>doesNotUnderstand: #<
Receiver: nil
Arguments and temporary variables:
aMessage: < 0
exception: MessageNotUnderstood: receiver of "<" is nil
resumeValue:nil
Receiver's instance variables:
nil
EncoderForV3PlusClosures(EncoderForV3)>>genPushLiteral:
Receiver: {an EncoderForV3PlusClosures}
Arguments and temporary variables:
literalIndex: nil
Receiver's instance variables:
comment:nil
pc: nil
scopeTable: a Dictionary('category'->{category}
'classPool'->{classPool} 'envir...etc...
nTemps: 0
supered:false
requestor: nil
class: StringTest class
selector: #lastStoredRun
literalStream: a WriteStream {#Dictionary->Dictionary. #add:.
#'->'. #passed. #...etc...
selectorSet:a Dictionary(#*->{*} #+->{+} #-->{-}
#'->'->{->} #/->{/} #'//'->{/...etc...
litIndSet: a
Dictionary(#Dictionary->Dictionary->{Dictionary} #Set->Set->{Set} ...etc...
litSet: a LiteralDictionary(size 302)
sourceRanges: a Dictionary(size 309)
globalSourceRanges: an OrderedCollection({'Dictionary'. (20
to: 29). false} {'S...etc...
addedSelectorAndMethodClassLiterals:false
stream: {an EncoderForV3PlusClosures}
position: 0
rootNode: lastStoredRun
^ Dictionary new add: #passed -> (Set new add: #testAs...etc...
blockExtentsToLocals: nil
EncoderForV3PlusClosures(BytecodeEncoder)>>sizeOpcodeSelector:withArguments:
Receiver: {an EncoderForV3PlusClosures}
Arguments and temporary variables:
genSelector:#genPushLiteral:
args: #(nil)
Receiver's instance variables:
comment:nil
pc: nil
scopeTable: a Dictionary('category'->{category}
'classPool'->{classPool} 'envir...etc...
nTemps: 0
supered:false
requestor: nil
class: StringTest class
selector: #lastStoredRun
literalStream: a WriteStream {#Dictionary->Dictionary. #add:.
#'->'. #passed. #...etc...
selectorSet:a Dictionary(#*->{*} #+->{+} #-->{-}
#'->'->{->} #/->{/} #'//'->{/...etc...
litIndSet: a
Dictionary(#Dictionary->Dictionary->{Dictionary} #Set->Set->{Set} ...etc...
litSet: a LiteralDictionary(size 302)
sourceRanges: a Dictionary(size 309)
globalSourceRanges: an OrderedCollection({'Dictionary'. (20
to: 29). false} {'S...etc...
addedSelectorAndMethodClassLiterals:false
stream: {an EncoderForV3PlusClosures}
position: 0
rootNode: lastStoredRun
^ Dictionary new add: #passed -> (Set new add: #testAs...etc...
blockExtentsToLocals: nil
EncoderForV3PlusClosures(BytecodeEncoder)>>sizePushLiteral:
Receiver: {an EncoderForV3PlusClosures}
Arguments and temporary variables:
literalIndex: nil
Receiver's instance variables:
comment:nil
pc: nil
scopeTable: a Dictionary('category'->{category}
'classPool'->{classPool} 'envir...etc...
nTemps: 0
supered:false
requestor: nil
class: StringTest class
selector: #lastStoredRun
literalStream: a WriteStream {#Dictionary->Dictionary. #add:.
#'->'. #passed. #...etc...
selectorSet:a Dictionary(#*->{*} #+->{+} #-->{-}
#'->'->{->} #/->{/} #'//'->{/...etc...
litIndSet: a
Dictionary(#Dictionary->Dictionary->{Dictionary} #Set->Set->{Set} ...etc...
litSet: a LiteralDictionary(size 302)
sourceRanges: a Dictionary(size 309)
globalSourceRanges: an OrderedCollection({'Dictionary'. (20
to: 29). false} {'S...etc...
addedSelectorAndMethodClassLitera
Re: [Pharo-project] [BUG]UndefinedObject(Object)>>doesNotUnderstand: #
I ran the tests (all Collection related [4986] ones) then I action-clicked in the upper right pane (which when I started was all green ;-). The Test Runner offered a three choices menu, the middle one (which I was interested in) "Store result as progress reference", the I clicked there and... MNU Em 30/11/2009 17:36, Stéphane Ducasse escreveu: thanks can you let us knw the exact sequence your did? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] External integers
Bill, Dolphin is a single platform Smalltalk so it is conceptually easy to deal with DWORD, etc. However your mention to FFI raises an interesting question, since once you start to connect with functionality written in other languages this has to be accounted for. It would be nice to know how to deal with these things (I cannot find any docs about this). -- Cesar Rabak Em 01/12/2009 16:10, Schwab,Wilhelm K escreveu: Hello all, Dolphin defines ExternalInteger and various subclasses such as DWORD under ExternalStructure. I will oscillate between caring about the details (for FFI uses??) and simply wanting the classes in the image to pacify my code. Is there a correct way to deal with such things? Not seeing anything, I created ExternalInteger that uses a ByteArray and DWORD under it, acting as a glorified value holder. Please let me know if I am missing an existing solution. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue # 1498 "Collections should not accept non integer indexes"
I'm trying to follow the directions given at: http://code.google.com/p/pharo/wiki/HowToContribute. However, after the SLICE asks for the first comment, it freezes the image and the small window "Writing definitions" stays at 50% progress and nothing happens then. So I'll resort to the alternative plan, which is to send the changeset to this list. On a core image update #11067 the Collection tests are all green. Running all tests show one error and two failures not related to the changed methods. -- Cesar Rabak 'From PharoCore1.0rc1 of 19 October 2009 [Latest update: #10498] on 1 December 2009 at 6:41:39 pm'! !TIndexAccess methodsFor: 'tests - index access' stamp: 'CesarRabak 11/30/2009 18:29'! testIntegerIndex "self debug: #testIntegerIndex" | collection | collection := self collectionMoreThan1NoDuplicates. self should: [collection at: 2.2] raise: Error! ! !TPutTest methodsFor: 'tests - puting with indexes' stamp: 'CesarRabak 12/1/2009 18:10'! testIntegerAtPut "self debug: #testIntegerAtPut" self should: [self nonEmpty at: 2.2 put: self aValue] raise: Error ! ! !Object methodsFor: 'accessing' stamp: 'CesarRabak 11/30/2009 18:34'! at: index "Primitive. Assumes receiver is indexable. Answer the value of an indexable element in the receiver. Fail if the argument index is not an Integer or is out of bounds. Essential. See Object documentation whatIsAPrimitive." index isInteger ifTrue: [self class isVariable ifTrue: [self errorSubscriptBounds: index] ifFalse: [self errorNotIndexable]]. self errorNonIntegerIndex! ! !Object methodsFor: 'accessing' stamp: 'CesarRabak 11/30/2009 19:54'! at: index put: value "Primitive. Assumes receiver is indexable. Store the argument value in the indexable element of the receiver indicated by index. Fail if the index is not an Integer or is out of bounds. Or fail if the value is not of the right type for this kind of collection. Answer the value that was stored. Essential. See Object documentation whatIsAPrimitive." index isInteger ifTrue: [self class isVariable ifTrue: [(index between: 1 and: self size) ifTrue: [self errorImproperStore] ifFalse: [self errorSubscriptBounds: index]] ifFalse: [self errorNotIndexable]]. self errorNonIntegerIndex! ! !Object methodsFor: 'accessing' stamp: 'CesarRabak 11/30/2009 19:11'! basicAt: index "Primitive. Assumes receiver is indexable. Answer the value of an indexable element in the receiver. Fail if the argument index is not an Integer or is out of bounds. Essential. Do not override in a subclass. See Object documentation whatIsAPrimitive." index isInteger ifTrue: [self errorSubscriptBounds: index]. self errorNonIntegerIndex! ! !Object methodsFor: 'accessing' stamp: 'CesarRabak 12/1/2009 18:30'! basicAt: index put: value "Primitive. Assumes receiver is indexable. Store the second argument value in the indexable element of the receiver indicated by index. Fail if the index is not an Integer or is out of bounds. Or fail if the value is not of the right type for this kind of collection. Answer the value that was stored. Essential. Do not override in a subclass. See Object documentation whatIsAPrimitive." index isInteger ifTrue: [(index between: 1 and: self size) ifTrue: [self errorImproperStore] ifFalse: [self errorSubscriptBounds: index]]. self errorNonIntegerIndex! ! !Interval methodsFor: 'accessing' stamp: 'CesarRabak 11/30/2009 19:18'! at: anInteger "Answer the anInteger'th element." anInteger isInteger ifFalse: [self errorNonIntegerIndex]. (anInteger between: 1 and: self size) ifTrue: [^start + (step * (anInteger - 1))] ifFalse: [self errorSubscriptBounds: anInteger]! ! !OrderedCollection methodsFor: 'accessing' stamp: 'CesarRabak 11/30/2009 23:53'! at: anInteger put: anObject "Put anObject at element index anInteger. at:put: cannot be used to append, front or back, to an ordered collection; it is used by a knowledgeable client to replace an element." anInteger isInteger ifFalse: [self errorNonIntegerIndex]. (anInteger < 1 or: [anInteger + firstIndex - 1 > lastIndex]) ifTrue: [self errorNoSuchElement] ifFalse: [^array at: anInteger + firstIndex - 1 put: anObject]! ! ___ Pharo-project mailing list Pharo-pr
Re: [Pharo-project] Issue 332, 1489, 1529: arithmetic protocols extracted from core
Em 02/12/2009 01:41, Simon Denier < simon.den...@inria.fr > escreveu: > > On 1 déc. 2009, at 21:07, csra...@bol.com.br wrote: > > > I'mtryingtofollowthedirectionsgivenat: > >http://code.google.com/p/pharo/wiki/HowToContribute. > > However, after the SLICE asks for the first comment, it freezes > > the image and the small window "Writing definitions" stays at 50% > > progress and nothing happens then. > Hi Cesar, I took your changeset and prepared a Slice, I did not > have any problem. Nice to know, Simon. Just to understand how I can troubleshoot this: did you empoly a core or dev image to do the Monticello stuff? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issue 332, 1489, 1529: arithmetic protocols extracted from core
Miguel, I've used the core image and just had it updated as the first bullet of instructions direct. I was just curious :-) Em 02/12/2009 16:42, Miguel Enrique Cobá Martinez < miguel.c...@gmail.com > escreveu: El mié, 02-12-2009 a las 10:56 -0200, csra...@bol.com.br escribió: > Em 02/12/2009 01:41, Simon Denier < simon.den...@inria.fr > escreveu: > > > > On 1 déc. 2009, at 21:07, csra...@bol.com.br wrote: > > > > > I'mtryingtofollowthedirectionsgivenat: > > >http://code.google.com/p/pharo/wiki/HowToContribute. > > > However, after the SLICE asks for the first comment, it freezes > > > the image and the small window "Writing definitions" stays at 50% > > > progress and nothing happens then. > > > Hi Cesar, I took your changeset and prepared a Slice, I did not > > have any problem. > > Nice to know, Simon. Just to understand how I can troubleshoot this: did you > empoly a core or dev image to do the Monticello stuff? > Always use a core image to prepare the SLICES. Cheers > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] On issue Issue 1155: "Renaming of a class do not changes title of a System Browser"
Pertaining the bug #1155 http://code.google.com/p/pharo/issues/detail?id=1155, it seems to me that we need to register the change for the class name so the SystemWindow gets updated: O2PackageBrowser class>>registerForNotifications Smalltalk at: #SystemChangeNotifier ifPresent: [:cls | (cls uniqueInstance) noMoreNotificationsFor: self; notify: self ofSystemChangesOfItem: #class change: #Added using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Modified using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Renamed using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Commented using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Recategorized using: #classMoved:; notify: self ofSystemChangesOfItem: #class change: #Removed using: #classModified:; notify: self ofSystemChangesOfItem: #method change: #Added using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Modified using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Recategorized using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Removed using: #methodModified: ]. However I could not find how to assemble a #notify:chnage:using: message in order to have the model (O2PackageBrowser) notified. . . If some more knowledgeable on this hierarchy can enlighten me I think we can solve this easily, no? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class comment displayed
I would like to point out that writing comments for the class definition is not a poor job to be done since it can very easily be read clicking in the '?' button of the majority of the browsers. I dare to write that from a quality POV we should put as an "issue" for the release of version 1.0 that all comments in the core image must be written and verified. It is a little scary when one is browsing a class and finds a "THIS CLASS HAS NO COMMENT!" or a "A is x."... BTW, an interesting behaviour (at least to my expectations) happens in the core image (where I believe the ST-80 look for browser is the default): if you click in a class that has a "...." in the comment the bottom pane shows the "THIS CLASS HAS NO COMMENT!" in red. I surmise a reasonable machinery has been put on this pane to be able to display such message, isn't it? -- Cesar Rabak Em 03/12/2009 14:42, Stéphane Ducasse escreveu: On Dec 3, 2009, at 5:35 PM, Lukas Renggli wrote: > Hi Stef > >> I hope that the trip was good. > > Yep, just arrived home. Reboot :) > >> this was to get the comment below the class definition >> This is in the preferences at least on my image (rc1.0). > > That split class-definition/class-comment view is only available in > the ST-80 browser. I think that would be difficult to implement in OB. ok too bad because nicolas made me think that we are doing a poor job at pushing people to write comments since nobody can easily read them. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class comment displayed
YES! This would facilitate the automatic checking for spelling errors and other related items w.r.t. the text itself. my .01... -- Cesar Rabak Em 03/12/2009 15:08, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Since several years I think that we lack a tool to get really fast browsing of class comments. May be that now that we have Momo tree we could have a tree ClassA class comment method method comment ClassB class comment method method comment Alain do you have an example on how to play with Momo Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about keys returning a set
Em 04/12/2009 05:58, Lukas Renggli < reng...@gmail.com > escreveu: > I wonder if ever something along the following lines was considered? > > Dictionary>>keys > "Answer a Set containing the receiver's keys." > > | result | > result := Set basicNew. > result setTally: tally array: (array collect: [ :each | > each isNil ifFalse: [ each key ] ]). > ^ result Why not: | result | result := Set basicNew. result setTally: tally array: (array collect: [ :each | each ifNil: [ each key ] ]). ^ result A bit more OO ;-) Reading Andrés' book is making more aware of those subtleties :-D My .01... - Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about keys returning a set
I think this last assertion has to be tempered by another statistic: which is the relationship between iteration (a.k.a. uses of) and creation? -- Cesar Rabak Em 04/12/2009 09:48, Stéphane Ducasse escreveu: this is interesting to see that this is still a guess game. Even with these numbers I cannot evaluate what could be a slowdown/pseed up impact on the complete system. I imgain that the ietration slow down should be minimal and compensated by the creation speed up. May be in the future when system will have a better knowledge of themselves we may end up having better tools... ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] christmas coding parties?
Is there a means of joining via Skype and/or IRC? Em 04/12/2009 09:57, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Hi all I would like to organize a couple of coding parties around christmas. The 18 of december? is one possibility (even if I can only start at 11h). So if some of you are close to lille during holidays we could have fun coding together. I would like to organize a moose day too. I want to code what I have in mind with CAnalyzer and mondrian. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How do I know which issues are resolved in each new release?
Marcus, This brings a question to me: is there a sort of API or web service we could use (obviously for calling from inside Pharo) to post at the Pharo's Twitter account? I surmise that doing that for the blog would be 'easier' :-) -- Cesar Rabak Em 04/12/2009 10:09, Marcus Denker < den...@acm.org > escreveu: Hello, Yes, we should improve information on what changed I would want to have a changelog for any image that is downloaded. And we should use the Blog. And Twitter. And. And. We will do all that, but not today :-) Marcus ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about keys returning a set
I see. . . this is an interesting observation (about the performance penalty) on the issues of going really OO. In retrospect I think (once the concerns about the possibility of changing the semantics of the returned object) this is the way to go. We really need to have a competitive (in terms of raw computing performance) system! Em 04/12/2009 16:46, Lukas Renggli < reng...@gmail.com > escreveu: Yeah, this was my first attempt, but this implementation is ways slower. The block activations with #collect: matters. My implemebtation only calls primitives or inlined constructs. Not nice to look at, but as fast as it can get. Lukas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] christmas coding parties?
I expect you folks make the scheduling invitation giving the time in UTC, so I can check my availability ;-) Em 04/12/2009 17:21, Mariano Martinez Peck < marianop...@gmail.com > escreveu: why not? If skype is reachable from where we are, I have no problem :) Ahh the time ;) Take into consideration the difference between your time and our. Best, Mariano On Fri, Dec 4, 2009 at 7:52 PM, wrote: Is there a means of joining via Skype and/or IRC? Em 04/12/2009 09:57, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Hi all I would like to organize a couple of coding parties around christmas. The 18 of december? is one possibility (even if I can only start at 11h). So if some of you are close to lille during holidays we could have fun coding together. I would like to organize a moose day too. I want to code what I have in mind with CAnalyzer and mondrian. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How do I know which issues are resolved in each new release?
OK! I'll swamped until the end of this week, but will look for information on this approach. I think I'll need to assemble an account in Twitter for myself also :-| -- Cesar Rabak Em 05/12/2009 08:28, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: we can use soap for example and I would really like to have an nice example :) Stef On Dec 4, 2009, at 7:55 PM, csra...@bol.com.br wrote: > Marcus, > > This brings a question to me: is there a sort of API or web service we could > use (obviously > for calling from inside Pharo) to post at the Pharo's Twitter account? > > I surmise that doing that for the blog would be 'easier' :-) > > -- > Cesar Rabak > > > Em 04/12/2009 10:09, Marcus Denker < den...@acm.org > escreveu: > > > Hello, > > Yes, we should improve information on what changed I would want to have a > changelog for any image that is downloaded. And we should use the Blog. And > Twitter. And. And. > We will do all that, but not today :-) > > Marcus > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Protocol extension proposal: Boolean>>asBit ?
I understand the motivation and the implementation, but IMNHO the name of the method should be #asSmallInteger or if you want more general #asNumber. Returning 1 or 0 is not the same thing as returning a bit, except if we agree on creating a class called bit where the operations on it abide to what it is expected for a bit. my .01... -- Cesar Rabak Em 05/12/2009 08:44, Igor Stasenko < siguc...@gmail.com > escreveu: I currently writing a code which looks like: a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]). And i get somewhat tired repeating the same pattern in multiple places. So, i thinking , maybe #asBit convenience method could be useful? True>>asBit ^ 1 False>>asBit ^ 0 so, then, in case of need like above, we could write much shorter expressions: a := some numeric expression + someBoolean asBit. And its much less error prone comparing to #ifTrue:ifFalse:, since i found its relatively easy to make a mess (swapping 1 with 0), especially, when you having negations in expression, because once you see: (someBoolean not ifTrue: [1] ifFalse: [0]) you always tempted to write it as: (someBoolean ifTrue: [0] ifFalse: [1]). or as: (someBoolean ifFalse: [1] ifTrue: [0]). but once you start playing with it, its very easy to shoot into own feet if you are not careful. But if we could add #asBit, then we could write: someBoolean not asBit which is much more: a) concise & cleaner b) error proof -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] EventInterceptor and MessageSendTree
Em 06/12/2009 05:25, Hernán Morales Durand escreveu: > Dear all, > I've attached a little cool tool for intercepting Morphic events I > just resurrected today, from the class comments: [snipped] Interesting! Let's see if with help of it we manage to squash two bugs pending for release of Pharo 1.0!! -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Protocol extension proposal: Boolean>>asBit ?
Cédrick, I understand the diplomacy of the suggestion and I think it sounds like an interesting compromise. Before we jump at it, let me ask some questions: Does a class called BitNumber exists in the present (core) Pharo hierarchy? Does it makes sense to add a class like this? Which behaviour for BitNumber is not already subsumed by Number? my .001... -- Cesar Rabak Em 06/12/2009 11:36, Cédrick Béler < cdric...@gmail.com > escreveu: 2009/12/5 I understand the motivation and the implementation, but IMNHO the name of the method should be #asSmallInteger or if you want more general #asNumber. Why not #asBitNumber ? Returning 1 or 0 is not the same thing as returning a bit, except if we agree on creating a class called bit where the operations on it abide to what it is expected for a bit. my .01... Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] New User Experience Suggestion for 1.0
+1 It should not be that dangerous, it's only matter of saving an image with a workspace with the text in it. -- Cesar Rabak Em 07/12/2009 21:51, Tim Mackinnon < tamackin...@gmail.com > escreveu: Guys - do you think you might consider bringing back the little Readme Workspace in the final 1.0 image (or maybe 1.1)? For new users - the blank screen is a bit intimidating, and with Pharo looking pretty good these days - I think new users are tempted to try it out - however its not easy to get started with a blank screen. I recall ages ago (and maybe this was the old Squeak image) there was a workspace with a few instructions - like the url to launch your web browser against - and a comment with the username and password for administering seaside. It's probably handy to have the url for Pharo by example as well as the Seaside online book. And finally a few doits and tips for launching a Class browser and common preferences to consider changing. I'm not sure if this is easy to do in your distribution script (hopefully it is a script) - and I also don't want to introduce anything risky into 1.0 (I am constantly anxious that some of the changes whizzing by are going into 1.0 - and stability is of the essence to get a good solid release out). But certainly it would make the initial new user experience that little bit better. Tim ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Is there in Pharo a class with the functionality of PrintingConverter?
I think it is specific in VW (I don't remember in Dolphin) but for formating numbers in strings, etc. like this class does. Tried looking for classes and methods (w/method finder) e/o success! -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] package documentation viewer
I also vote for having it running at Pharo website. However it gives another opportunity to my canvassing: it is imperative that the comments written (class and methods) be accurate and uptodate!! -- Cesar Rabak Em 09/12/2009 11:06, Alexandre Bergel < alexan...@bergel.eu > escreveu: Looks good. Maybe this could be part of the Pharo website no ? Alexandre On 9 Dec 2009, at 07:49, laurent laffont wrote: > Hi, > > for fun and *for me*, I've made a small Seaside app to quickly > browse all documentation in a Pharo image. > It's package oriented, all classes and selectors comment on a > single page, so I can use search and print functions of my web > browser. > > Someone might have a use of it. It's here: > http://www.squeaksource.com/SimpleWebDoc.html > Screenshots: http://picasaweb.google.fr/laurent.laffont/Simplewebdoc > > Laurent > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] New User Experience Suggestion for 1.0
Adrian, I understand there is some reluctance in adding a "long text" (for the arbitrary definition of 'long'). As a counter argument, I would say that Squeak images are less laconic and two other Smalltalks I'm aware of (VW and ST/X) also carry a more thorough introduction for people who are trying first time. As some others that report working in trains or other places with limited (or none conectivity), it would be nice if we could have an image where the initial tour could be done without need to web access. More often than not, we download a lot of stuff to try it while waiting in some glass doors, airports, etc.! In retrospect, I think the way as Squeak had a welcome.txt or readme.txt that could even be read before launching the application would be a fine addition to our tools to make Pharo more (new) user friendly. my 0.01999... -- Cesar Rabak Em 08/12/2009 06:39, Adrian Lienhard escreveu: Please note that there is an issue in the tracker that discusses this. I've suggested to add a workspace but do not add a long text and code but link to the pages on the web that contain it so that we can more easily make updates. http://code.google.com/p/pharo/issues/detail?id=1479 Tim, would that be helpful for new users of Pharo? Cheers, Adrian On Dec 8, 2009, at 09:23 , Damien Cassou wrote: > Hi Tim, > > On Tue, Dec 8, 2009 at 12:51 AM, Tim Mackinnon > wrote: >> Guys - do you think you might consider bringing back the little >> Readme Workspace in the final 1.0 image (or maybe 1.1)? > > there is no technical difficulty. Could you please provide a text? I > will take care of putting it in a workspace. There may be something in > the Pharo wiki already. > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] package documentation viewer
I already started working on this, give me the weekend and I'll post results. If they are worth, I'll put an issue for this. -- Cesar Rabak Em 09/12/2009 21:30, Simon Denier < simon.den...@inria.fr > escreveu: On 9 déc. 2009, at 19:11, csra...@bol.com.br wrote: > I also vote for having it running at Pharo website. > > However it gives another opportunity to my canvassing: it is imperative that > the comments written (class and methods) be accurate and uptodate!! Can someone quickly run some query to see how bad it is? That is, how many classes without comment or with the generic template? > > -- > Cesar Rabak > > > Em 09/12/2009 11:06, Alexandre Bergel < alexan...@bergel.eu > escreveu: > > > Looks good. Maybe this could be part of the Pharo website no ? > > Alexandre > > > On 9 Dec 2009, at 07:49, laurent laffont wrote: > >> Hi, >> >> for fun and *for me*, I've made a small Seaside app to quickly >> browse all documentation in a Pharo image. >> It's package oriented, all classes and selectors comment on a >> single page, so I can use search and print functions of my web >> browser. >> >> Someone might have a use of it. It's here: >> http://www.squeaksource.com/SimpleWebDoc.html >> Screenshots: http://picasaweb.google.fr/laurent.laffont/Simplewebdoc >> >> Laurent >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Keyboard Shortcuts in Pharo?
Em 11/12/2009 05:44, Lukas Renggli < reng...@gmail.com > escreveu: > > [snip] > Yeah, I agree on all ;-) > > > will with every next hit on left arrow select a larger block of > > code. So if my cursor is on a message send, it will first select > > the message send, next the receiver and the message send, next: if > > this was a nested, select the part out of that, and so forth. This > > is very handy if you for instance want to do a extract method > > refactoring on some part of the code. Just quickly select it using > > this Alt-Shift selection and extract it. > That's a cool idea. I will add it to the refactoring tools. +1 > > > - Which brings me to the refactoring shortcuts, which I'm missing > > the most. * The most important one is rename. In Eclipse if I > > select a field, a temporary var, a message, a class, anything that > > can be renamed; I can always hit Alt-Shift-R to rename it. I don't > > have to go into a menu, refactor class, or refactor method, or > > refactor source with the mouse to select rename. Just click on it, > > hit the shortcut, type the new name and hit Enter. > The problem is that Pharo already binds all possible keyboard > shortcuts to something, which leaves no space for other tools like > the refactoring engine. I think we could have some leeway if we give up to the present double mapping of some short cuts that accept the Alt and Cmd prefixes to do the same thing (at least in Windows is worse than that because sometimes this double mapping works sometimes does not. > > How are experienced Smalltalkers feeling about this? > Safara was an attempt to implement a replacement for the current > text editor, where nothing was hardcoded but everything could be > configured by the tool (highlighting, completing, shortcuts, > ...). Unfortunately this project never made it into a useable > state. Writing a text editor is difficult. Besides, I _think_ putting a completely reconfigurable environment in Pharo's toolset will create the anxiety of the "paradox of choice" without bringing too much added value. We already have lot of 'fun' having do spread remarks all over the documentation about the appeareance of the tools and still have a half baked solution for the naming of mouse buttons, imagine the added complexity of having to all the time have to put remarks on keyboard shorcuts!! ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Keyboard Shortcuts in Pharo?
Em 11/12/2009 08:02, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: > Dec 11, 2009, at 9:05 AM, Bart Gauquie wrote: > > The problem is that Pharo already binds all possible keyboard > shortcuts to something, which leaves no space for other tools like > the refactoring engine. > Is it not possible to throw away some of the shortcuts defined? I'd > rather have a limited set of shortcuts which are used often, than > defining a lot which are almost never used. I noticed for instance > in the list that there is a shortcut Ctrl+T which inserts ifTrue:[] > ; to my humble opinion, that is way to specific; and I'm not sure > anybody is using this one. I'd rather use Ctrl-T then to open a new > Type (class) or something. Ctrl+Shift+T and Ctrl+Shift+F are nice shorcuts that I vote for staying ;-). Also I would vote for a similar to VW's Ctrl+g for inserting the := sign now that we deprecated for good the undescore. > Another one is Alt - t pressed no the world view to 'find a > transcript'. Is it not better then to find a way to quickly navigate > between windows in general, so for instance, hit a shortcut > anywhere, you get a list of all windows, and by just typing t for > Transcript, and hit Enter, you are already in the transcript window. This is weird, because in some of my images I'm positive that a certain key combination makes a kind of 'round robbin' of open windows. . . > > should really have an overview and see what we can do. > Positively. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Regarding the shortcuts
Well then be sure they're not 100% working. Also, we should get a way of
having the
shortcuts less dependent on platform (ex. the prefix key to what we need to
find a
way of referring to them in an homogeneous way like, say, Emacs).
In PBE book a change was done towards a unified terminology for the mouse
buttons. I
know still there are some issues with that, but let's move on!
--
Cesar Rabak
Em 12/12/2009 20:49, Mariano Martinez Peck < marianop...@gmail.com > escreveu:
Now that you are discussing this in another thread..I remember that in August I
opened this ticket: http://code.google.com/p/pharo/issues/detail?id=1042
For those you have ever seen the list of shortcut, here they are (I am not sure
100% are working now).
Cheers,
Mariano
Lower-case command keys
(use with Cmd key on Mac and Alt key on other platforms)
a Select all
b Browse it (selection is a class name or cursor is over a class-list or
message-list)
c Copy selection
d Do it (selection is a valid expression)
e Exchange selection with prior selection
f Find
g Find again
h Set selection as search string for find again
i Inspect it (selection is a valid expression, or selection is over an
inspect-ilst)
j Again once (do the last text-related operation again)
k Set font
l Cancel
m Implementors of it (selection is a message selector or cursor is over a
class-list or message-list)
n Senders of it (selection is a message selector or cursor is over a
class-list or message-list)
o Spawn current method
p Print it (selection is a valid expression)
q Query symbol (toggle all possible completion for a given prefix)
r Recognizer
s Save (i.e. accept)
t Finds a Transcript (when cursor is over the desktop)
u Toggle alignment
v Paste
w Delete preceding word (over text); Close-window (over morphic desktop)
x Cut selection
y Swap characters
z Undo
Note: for Do it, Senders of it, etc., a null selection will be expanded to a
word or to the current line in an attempt to do what you want. Also note that
Senders/Implementors of it will find the outermost keyword selector in a large
selection, as when you have selected a bracketed expression or an entire line.
Finally note that the same cmd-m and cmd-n (and cmd-v for versions) work in the
message pane of most browsers.
Upper-case command keys
(use with Shift-Cmd, or Ctrl on Mac
or Shift-Alt on other platforms; sometimes Ctrl works too)
A Advance argument
B Browse it in this same browser (in System browsers only)
C Compare argument to clipboard
D Duplicate
E Method strings containing it
F Insert 'ifFalse:'
G fileIn from it (a file name)
H cursor TopHome:
I Inspect via Object Explorer
J Again many (apply the previous text command repeatedly until the end of
the text)
K Set style
L Outdent (move selection one tab-stop left)
M Select current type-in
N References to it (selection is a class name, or cursor is over a
class-list or message-list)
O Open single-message browser (in message lists)
P Make project link
R Indent (move selection one tab-stap right)
S Search
T Insert 'ifTrue:'
U Convert linefeeds to carriage returns in selection
V Paste author's initials
W Selectors containing it (in text); show-world-menu (when issued with
cursor over desktop)
X Force selection to lowercase
Y Force selection to uppercase
Z Capitalize all words in selection
Other special keys
Backspace Backward delete character
Del Forward delete character
Shift-Bksp Backward delete word
Shift-Del Forward delete word
Esc Pop up the Desktop Menu
\ Send top window to back
Cursor keys
left, right,
up, down Move cursor left, right, up or down
Ctrl-left Move cursor left one word
Ctrl-right Move cursor right one word
Home Move cursor to begin of line or begin of text
End Move cursor to end of line or end of text
PgUp, Ctrl-up Move cursor up one page
PgDown, Ctrl-Dn Move cursor down one page
Note all these keys can be used together with Shift to define or enlarge the
selection. You cannot however shrink that selection again, as in some other
systems.
Other Cmd-key combinations (not available on all platforms)
Return Insert return followed by as many tabs as the previous line
(with a further adjustment for additional brackets in that line)
Space Select the current word as with double clicking
Enclose the selection in a kind of bracket. Each is a toggle.
(not available on all platforms)
Ctrl-( Enclose within ( and ), or remove enclosing ( and )
Ctrl-[ Enclose within [ and ], or remove enclosing [ and ]
Crtl-{ Enclose within { and }, or remove enclosing { and }
Ctrl-< Enclose within < and >, or remove enclosing < and >
Ctrl-' Enclose within ' and ', or remove enclosing ' and '
Ctrl-" Enclose within " and ", or remove enclosing " and
Re: [Pharo-project] Regarding the shortcuts
Em 13/12/2009 07:03, Michael Rueger escreveu: > csra...@bol.com.br wrote: > > Well then be sure they're not 100% working. Also, we should get a > > way of having the shortcuts less dependent on platform (ex. the > > prefix key to what we need to find a way of referring to them in > > an homogeneous way like, say, Emacs). > being a long time smalltalk user, how does Emacs do it? Emacs coming from an old heritage and being multiplataform as well, 'standardized' the names Control and Meta, this last one normally maps to Alt key in PCs but it is called Meta in Workstations. There is no need to explicitly talk about Shift if you are only working with alphanumeric shortcuts, if we decide to employ the ten to twelve "function keys", then the Shift prefix has to come in play. > In Sophie we used I think shift, command, control to identify the > modifier keys and mapped them in the platform classes to the > platform specific bits. We also had a key dispatcher class with > instances configured for the different views so that all the > modifier etc handling was done in one place. IIUC 'command' can be the name we use for the command key in Macs and Alt for PCs, we've only to create a nomenclature, stick to it and use it consitently in the program and documentation. > > > In PBE book a change was done towards a unified terminology for > > the mouse buttons. I know still there are some issues with that, > > but let's move on! > What are the issues? Certain operations which used to be available on the three button mice now only work if you prefix the button with a Ctrl, and this behaviour it is not consistent, so from times to times you've to do an heuristic search of the menu you want to appear... -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Keyboard Shortcuts in Pharo?
Em 13/12/2009 11:11, Mariano Martinez Peck escreveu: Thinking aloud, I wonder if isn't better to have the 'feature' of duplicateAllControlAndAltKeys its sibbling duplicateSomeControlAndAltKeys removed and have only the Alt prefix for the Pharo related operations? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] package documentation viewer
Em 09/12/2009 21:30, Simon Denier escreveu: > On 9 déc. 2009, at 19:11, csra...@bol.com.br wrote: > > I also vote for having it running at Pharo website. > > However it gives another opportunity to my canvassing: it is > > imperative that the comments written (class and methods) be > > accurate and uptodate!! > > Can someone quickly run some query to see how bad it is? That is, > how many classes without comment or with the generic template? > I ran the following script in the Workspace: nocomments := Smalltalk allClasses select: [:c | c comment string prefixMatchesRegex: '. [A-z]+ is x+\.$']. The results in the images I have are: ++--+--+ |Image |update|result| ++--+--+ |1.0-dev | 10502| 954| ++--+--+ |1.1-core| 11097| 613| ++--+--+ | 1.1-dev| 11097| 967| ++--+--+ Doing the same exercise with a bloc [:c| c comment string isEmpty] returns no class. Is there another search string or way to detect other empty comments? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] package documentation viewer
Em 13/12/2009 19:00, Lukas Renggli escreveu: > > Is there another search string or way to detect other empty comments? > Smalltalk allClasses select: [ :class | class organization > classComment isEmpty ] Lukas, Your way is clever (I didn't know ClassOrganizer until this exchange)! OTOH, it rises all the numbers: ++---+---+ | Image| update|result | || | | ++---+---+ |1.0-dev | 10502 | 1831| ++---+---+ |1.1-core| 11098 |703| ++---+---+ | 1.1-dev| 11098 | 1795| ++---+---+ I think I'll open an issue in the tracker. -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Syntax highlighting changed in 10500?
+ 1 Em 14/12/2009 17:32, Tudor Girba escreveu: Hi, There are two things that I like very much in the previous color scheme. 1. the local variables and the parameters were displayed with gray and instance variables and classes were displayed with black. This had the nice advantage of distinguishing both the classes and the instance variables in one glance. You could argue that this introduces a new visual variable, but the choice of the coloring was actually quite intuitive and with basically no cost: - all variables are shown with shades of gray (thus requiring only one mental mapping), and - the darkness is used to show the "prominence" of a variable: the larger the scope the darker the variable 2. The other nice thing in the previous coloring is the coloring of matching parentheses. This is quite nice when using blocks for scripting. Cheers, Doru ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problems with Czech accented characters
I'm puzzled: did you install the new environment in a folder which don't have the subfolder "fonts"? That being so, how did you 'import' Dejavu Czech font, then? If you go to System->Preferences->Standard System Fonts->list font... do you see the Czech letters in bottom part of window? Em 15/12/2009 15:40, "M. Polák" < ni...@nigol.cz > escreveu: Hi there, in older version of Pharo (pharo1.0-10487-BETAdev09.10.4) I was able to type Czech acc. chars (like ěščřžýáíé) without problems. But in most recent image, there is problem - instead of these characters, I see only '?'. What has changed? In the older version, there is 'Fonts' folder (none in recent version), so I suppose, that font handling is now different. Importing DejaVu Czech font into recent image doesn't help. Any suggestiions what I should do? Thanks, Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: [squeak-dev] Stuff
Em 16/12/2009 08:15, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: > You are too meta for me :) > What do you suggest in basic terms (yes this is too early for me > but my brain is starting to work again). > Now just a point. The squeak archives is full of our > history. Historians can go there and get the why we are here, what > we did and what was the problem at that point. And I believe that > they will really deeply understand. We only did one fork, some other > did multiple ones but apparently they had the rights to do > so. Newcomers can judge but may be they are wrong too :) > Guys let us continue build a shiny future this is more fun than ego > problems. My goal with pharo is > > - to create a world where people can make a living with an > open-source smalltalk. > - make it credible to the outside world (you know python, ruby, lua, java) > - make sure that we can adapt to the future changes > - be the substrate of people new inventions > - learn and expand my knowledge > Stef > PS: I should not have forwarded this mail, I was dreaming about a > better world but it does not exist so let us continue Stef, From time to time have a message like this is not something you should shy away from, but instead send it as a leadership call. Also, as Pharo is now a reality is no longer only a dream but a _vision_. As we're articulating on having funding, etc., it's becoming more than a vision but a _project_! my 0.01 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] MagmaBrowser
+1 Em 16/12/2009 08:31, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: I would like the same for UML document in packages :) Stef On Dec 16, 2009, at 11:29 AM, Mariano Martinez Peck wrote: > This is an excellent job. Congratulations Hernán. > > I have a questionhow could you draw the photo instead of the array of > bytes on the browser? I really hate when developing with seaside and I have > some pictures in my filelibrary class and when I browse them I see the array > of bits...but I want to see the picture!!! > > Thanks > > Mariano > > On Wed, Dec 16, 2009 at 11:18 AM, Hernán Morales Durand wrote: > Dear all, > I did a new Browser for the Magma object-oriented database, > implemented on top of the OmniBrowser framework. I've uploaded a demo > video in YouTube for the impatient : > http://www.youtube.com/watch?v=VxUaOFRHFPk > > The project Home Page is : http://swikicaicyt.homeip.net/WebOpus/56 > (you may access to other projects using > http://www.caicyt.gov.ar/letodoc/paquetes-publicados) you will find > there pre-built images ready for download for both Pharo and Squeak, > besides installation instructions for installing and testing the > MagmaBrowser in your image. Currently the status is under testing and > bug-fixing, and I know there is a lot of things I should include, but > you may take a look anyway as I browsed local repositories without > problems last times I've used it, so I hope you may find it useful > too. > > Finally, I want to publicly thank to Norberto Manzanos for letting me > doing this, Chris Muller for his nice reviews and the OmniBrowser > developers for mantaining such a great framework. > > Hernán > ___ > Magma mailing list > ma...@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?
I miss, perhaps because I'm used to in other Smalltalks. . . Em 16/12/2009 08:45, Damien Cassou < damien.cas...@gmail.com > escreveu: On Wed, Dec 16, 2009 at 9:29 AM, alesch wrote: > I remember I used a menu item in Squeak, but I cannot find in Pharo. You can't. Do you misss that feature? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?
I suggest simple text files with a known extension (.ws is normally used by some Smalltalks, so we could use it to avoid extension pollution...) Em 16/12/2009 09:51, Cédrick Béler < cdric...@gmail.com > escreveu: I think this is a valuable feature. Should we save in a particular file extension (.wst ? or simply text files ?) so that we can also have load opening from a a list of files of that format. This would be nice for tutorials instead of saving workspace content in a method. Cédrick 2009/12/16 alesch On Wed, Dec 16, 2009 at 11:45, Damien Cassou [via Smalltalk] <[hidden email]> wrote: On Wed, Dec 16, 2009 at 9:29 AM, alesch <[hidden email]> wrote: > I remember I used a menu item in Squeak, but I cannot find in Pharo. You can't. Do you misss that feature? Yes I do. View this message in context: Re: [Pharo-project] [newbee] How do I save the contents of a Workspace? Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?
OK. I agree that this advice is important enough to make part of the Welcome message we're suggesting to bring back too. OTOH, is we could version the scripts that would be very nice! Em 16/12/2009 15:16, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: So send it back and we will integrate it. No problem. But really you should use class side methods and versioned these damned scripts. Stef > Stef, > > I also miss the ready ability to save a workspace. With respect, it is not > your place to dictate working methods. You are correct that one can easily > over-use workspaces and under-use class methods. However, one can also > over-use class methods when a new test case is more appropriate. > > Rather than removing basic features, we should add capabilities to encourage > good practice by making things as easy as possible. Dolphin's IDE extensions > are a nice feature that I *really* miss in Pharo. One thing I added is a way > to create test case methods based on a currently selected method. Each class > can specify a TestCase subclass, and the methods were automatically named > based on the selected method's name; the code is generated and proposed for > optional compiling with warning of conflicts. > > Bill > > > -Original Message- > From: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz > Trepat > Sent: Wednesday, December 16, 2009 8:44 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] [newbee] How do I save the contents of a > Workspace? > > I really miss that feature. > In my oppinion it is very useful when you regularly use different images, or > when you frequently rebuild your development image from newer versions. > Also, I wonder if the Package Browser should be removed completely since it > does not even open now when you select it as preferred. > > > -Original Message- > From: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane > Ducasse > Sent: 16 December 2009 12:07 > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] [newbee] How do I save the contents of a > Workspace? > > for me it was political/educational to remove it. > > I saw too many people having expressions in workspace and not in class > methods (not versioned with the code). > because if this is really important why not put it in a class method? > Then you load the code and of course you do not get the magic example beacuse > they were in the wonderfull scripts left in the other images. > > Stef > > On Dec 16, 2009, at 12:51 PM, Cédrick Béler wrote: > >> I think this is a valuable feature. >> >> Should we save in a particular file extension (.wst ? or simply text files >> ?) so that we can also have load opening from a a list of files of that >> format. This would be nice for tutorials instead of saving workspace content >> in a method. >> >> Cédrick >> >> 2009/12/16 alesch On Wed, Dec 16, 2009 at 11:45, >> Damien Cassou [via Smalltalk] <[hidden email]> wrote: >> >> On Wed, Dec 16, 2009 at 9:29 AM, alesch <[hidden email]> wrote: >>> I remember I used a menu item in Squeak, but I cannot find in Pharo. >> >> You can't. Do you misss that feature? >> >> Yes I do. >> >> >> View this message in context: Re: [Pharo-project] [newbee] How do I save the >> contents of a Workspace? >> >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of securities, > accuracy and completeness of information, viruses, confidentiality, legal > privilege, and legal entity disclaimers, available at > http://www.jpmorgan.com/pages/disclosures/email. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforg
Re: [Pharo-project] File Browser (was: Re: [newbee ] How do I save the contents of a Workspace?)
FWIW it happens the same way in the image updated to 11105. Em 16/12/2009 22:06, csra...@bol.com.br escreveu: If you go to more... you get this in a Windows machine. HTH -- Cesar Rabak Em 16/12/2009 19:19, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Thanks this is really strange. I do not see why on windows it would be different but good catch. Can you enter a bug entry ? Stef On Dec 16, 2009, at 10:12 PM, Levente Uzonyi wrote: > Quoting Stéphane Ducasse : > >> >> Can you show what you get? >> > > Sure, I attached it. The screenshot was taken from an 1.1-11105 image. (Note > that the mouse pointer is on the first list item, but you can't see it, > because it's a windows machine...) > > > Levente___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Rome port
On devel image 1.0 10502 (Windows XP SP3), I get the following in the Transcript: a MCOrganizationDefinition(#(#'Rome-BalloonCanvas'))a MCOrganizationDefinition(#(#'Rome-Base'))a MCOrganizationDefinition(#(#'Rome-PluginCanvas'))a MCOrganizationDefinition(#(#'Rome-Fonts'))a MCOrganizationDefinition(#(#'Rome-Demo'))a MCOrganizationDefinition(#(#'Rome-Reference'))a MCClassDefinition(RomePluginForm)a MCClassDefinition(RomePluginGlyphForm)a MCClassDefinition(RomePluginSourceForm)a MCClassDefinition(RomePluginTargetForm)a MCClassDefinition(RomePluginTargetFile)a MCClassDefinition(RomePluginPDFTarget)a MCClassDefinition(RomePluginPSTarget)a MCClassDefinition(RomePluginSVGTarget)a MCClassDefinition(ExtendedArray)a MCClassDefinition(RomeCanvas)a MCClassDefinition(RomePluginCanvas)a MCClassDefinition(RomeReferenceCanvas)a MCClassDefinition(RomeBalloonCanvas) RomeReferenceCanvas>>string:from:to: (OffsetTransform is Undeclared) RomeReferenceCanvas>>translateBy: (OffsetTransform is Undeclared) a MCClassDefinition(RomeClipshape)a MCClassDefinition(RomeDemo)a MCClassDefinition(RomeFill)a MCClassDefinition(RomeFont)a MCClassDefinition(RomeFreetypeFont)a MCClassDefinition(RomeFontFamily)a MCClassDefinition(RomeFontManager)a MCClassDefinition(RomeFontManagerHandle)a MCClassDefinition(RomeFreeTypeFileInfo)a MCClassDefinition(RomeGlyphCache)a MCClassDefinition(RomePath)a MCClassDefinition(RomeBalloonPath)a MCClassDefinition(RomePen)a MCClassDefinition(RomePolygonClipper)a MCClassDefinition(RomeFontNotFoundException) RomeReferenceCanvas>>string:from:to: (OffsetTransform is Undeclared) RomeReferenceCanvas>>translateBy: (OffsetTransform is Undeclared) I still have to find some docs so I can do any intelligent test in the loaded package!! HTH -- Cesar Rabak Em 18/12/2009 17:08, Alexandre Bergel < alexan...@bergel.eu > escreveu: Gofer new impara: 'RomePharo'; addPackage: 'Rome-BalloonCanvas'; addPackage: 'Rome-Base'; addPackage: 'Rome-PluginCanvas'; addPackage: 'Rome-Fonts'; addPackage: 'Rome-Demo'; addPackage: 'Rome-Reference'; load loads fine in a 10500 for me. Alexandre ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [BUG]ByteSymbol(Object)>>error:
I also opened an issue http://code.google.com/p/pharo/issues/detail?id=1638
where the stack and a screenshot can be seen.
In a nutshell, when you use Method Finder and from there start a Browser, you
get an MNU ByteSymbol>>hasWideCharacterFrom:to:.
Steps to reproduce:
1. Start the Method Finder
2. in the search pane write 'max:' and accept it
3. click in (first in my image) method 'detectMax:'
4. on the right upper pane click in "Collection detectMax:"
More details:
As can be seen in the screenshoot in the issue tracker, the method source *is
shown* but the Browser fails to render the method name's list and instead a
red with a yellow crossings appears instead.
If "venturously" another protocol is selected, the same red with yellow
crossing is shown and no more navigation to the method sources is possible.
19 December 2009 11:25 pm
VM: Win32 - IX86 - NT - Squeak3.10.2 of '5 June 2008' [latest update: #7179]
Image: PharoCore1.0rc1 [Latest update: #10502]
SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir E:\Pharo
Trusted Dir E:\Pharo\Cesar S. Rabak
Untrusted Dir C:\Documents and Settings\Cesar S. Rabak\Meus documentos\My Squeak
ByteSymbol(Object)>>error:
Receiver: #do:
Arguments and temporary variables:
aString:'MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:to:'
Receiver's instance variables:
#do:
[] in WorldState>>displayWorldSafely:
Receiver: a WorldState
Arguments and temporary variables:
err:'MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:to:'
rcvr: #do:
errCtx: O2LazyListMorph>>display:atRow:on:
errMorph: an O2LazyListMorph(3958)
Receiver's instance variables:
hands: an Array(a HandMorph(3216))
viewBox:0...@0 corner: 9...@720
canvas: a FormCanvas on: DisplayScreen(976x720x32)
damageRecorder: a DamageRecorder
stepList: a Heap(StepMessage(#stepAt: -> a
SystemWindow(1419))(a SystemWindow(1...etc...
lastStepTime: 22201329
lastStepMessage:nil
lastCycleTime: 22201348
commandHistory: a CommandHistory
alarms: a Heap()
lastAlarmTime: 22201329
BlockClosure>>valueWithPossibleArgs:
Receiver: [closure] in WorldState>>displayWorldSafely:
Arguments and temporary variables:
anArray:#('MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:to:' #do:)
Receiver's instance variables:
outerContext: WorldState>>displayWorldSafely:
startpc:73
numArgs:2
[] in BlockClosure>>ifError:
Receiver: [closure] in WorldState>>displayWorldSafely:
Arguments and temporary variables:
errorHandlerBlock: MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:to:
ex: [closure] in WorldState>>displayWorldSafely:
Receiver's instance variables:
outerContext: WorldState>>displayWorldSafely:
startpc:66
numArgs:0
BlockClosure>>valueWithPossibleArgs:
Receiver: [closure] in BlockClosure>>ifError:
Arguments and temporary variables:
anArray:an Array(MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:to:)
Receiver's instance variables:
outerContext: BlockClosure>>ifError:
startpc:40
numArgs:1
[] in MethodContext(ContextPart)>>handleSignal:
Receiver: BlockClosure>>on:do:
Arguments and temporary variables:
exception: MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:to:
Receiver's instance variables:
sender: BlockClosure>>ifError:
pc: 17
stackp: 3
method: a CompiledMethod(3772: BlockClosure>>on:do:)
closureOrNil: nil
receiver: [closure] in WorldState>>displayWorldSafely:
BlockClosure>>ensure:
Receiver: [closure] in MethodContext(ContextPart)>>handleSignal:
Arguments and temporary variables:
aBlock: [closure] in
MethodContext(ContextPart)>>handleSignal:
returnValue:nil
b: nil
Receiver's instance variables:
outerContext: MethodContext(ContextPart)>>handleSignal:
startpc:90
numArgs:0
MethodContext(ContextPart)>>handleSignal:
Receiver: BlockClosure>>on:do:
Arguments and temporary variables:
exception: MessageNotUnderstood:
ByteSymbol>>hasWideCharacterFrom:t
[Pharo-project] was "Re: About projects with Metacello"
I cannot find in the archives clues for that, so I'll ask here. Is there a reason we keep both O2 and OB in parallel? Can't we just get the best parts of one of the solutions and consider the other as the "trunk" or mainstream for Pharo? -- Cesar Rabak Em 20/12/2009 06:32, Lukas Renggli < reng...@gmail.com > escreveu: > I think it would be better to have ConfigurationOfRefactoring and two > other: ConfigurationOfOB and ConfigurationOfO2, which have the former > as a required project (and IIUC it was your first intention, right?). > This will reduce duplication of dependencies between projects. O2 breaks OB, if both are loaded. I suggest that the configurations should trigger a conflict when somebody tries to load both. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] was "Re: About projects with Metacello"
Em 20/12/2009 17:50, Mariano Martinez Peck escreveu: > On Sun, Dec 20, 2009 at 8:32 PM, wrote: > > I cannot find in the archives clues for that, so I'll ask here. > > Is there a reason we keep both O2 and OB in parallel? Can't we > just get the best parts of one of the solutions and consider the > other as the "trunk" or mainstream for Pharo? > > Of course we can and I really would like that also...but..who do it? OK, Mariano! Before we engage in "who'll do it" we have to have a clear vision on the _what_ to do it! If the project participant's all agree with this, we can open an issue specific to table what should be kept from the incumbent browser[s] to the one considered to be the next thing®. I surmase correctly O2 is the one to be fully developed and we should scavenge the interesting ideas from the other available implementations (IIUC including Whisker). Then we can see if the desired features fit in the present architecture (still thinking of O2) or if we should start from a lower ground implementing all the new ideas using Glamor (for example). Once the all effort is more or less understood, we can look for ways of getting resources for it (including the funding for people working in it, or chopping the tasks in chunks small enough that via Sprints and programming parties we arrive at our objective). I think Pharo would be a nice "example" for the Smalltalk community if we can get this kind of 'disperse engineering' to work! my 0.01 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] nil DNU #size
In PharoDev (PharoCore1.0rc1 Latest update: #10502) evaluting this expression: nil size. "Leads to a DNU Instances of UndefinedObject are not indexable" For some reason, at some moment the #size overload of the Object>>size was taken off (w.r.t. Squeak). This is weird because a lot of protocols that would work flawlessly (Null object pattern) now have to be patched for ifNil:[] or ifNotNil:[]. Also, Pharo coming from Squeak inheritance keeps the Object>>size implementation as: size "Primitive. Answer the number of indexable variables in the receiver. This value is the same as the largest legal subscript. Essential. See Object documentation whatIsAPrimitive." self class isVariable ifFalse: [self errorNotIndexable]. ^ 0 The version comment is "di 3/29/1999" so this is very old indeed. This particular decisions is now making even the Luka's suggestion to do Gofer update itself to fail with a MNU. . . Before I open an issue, I would like to know from the elder folks at the Pharo project if the decision to make this change in the accessing protocol of UndefinedObject was deliberated or we just stumbled a new bug? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: sort: and sortBlock:
I just would like to point out that English plus the use of some [of their] overloaded words may create havoc in a discussion. TreeSets would be a common data structure to implement *sorted* sets in Smalltalk parlance. Although /ordered/ and /sorted/ may be synonyms in lay English, in Smalltalk the use of "Ordered" in the Collection classes has to the property of being indexable and sequenceable which other languages will call the behaviour of "random access". just my 0.019 Em 23/12/2009 14:34, Adrian Kuhn < ak...@iam.unibe.ch > escreveu: Stéphane Ducasse writes: > >> I started to implement OrderedSet (OrderedCollection no duplicate) > >> but I think that I want probably UniqueOrdered. > >> I will publish what I have done and ask for feedback and that other can > >> improve. I like the idea of using the TraitsTest to have coherent sets of > >> behavior. > > > > Oh yeah, TreeSet ftw, missed that already sometime! > > what is TreeSet? The common data structure to implement ordered sets. Which one do you use? --AA ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: hasEqualElements:
Em 23/12/2009 16:10, Eliot Miranda < eliot.mira...@gmail.com > escreveu: > > Core.SequenceableCollection comparing > isSameSequenceAs: otherCollection > > "Answer whether the receiver's size is the same as otherCollection's > size, and each of the receiver's elements equal the corresponding > element of otherCollection." > > | size | > (size := self size) = otherCollection size ifFalse: [^false]. > 1 to: size do: [:index | > (self at: index) = (otherCollection at: index) ifFalse: [^false]]. > ^true > > i.e. trust the caller is providing a sequence and if > otherCollection doesn't implement at: there will be a run-time > error, hence any otherCollection isKindOf: SequenceableCollection is > just wasted cycles. > I don't think that "trusting the caller" makes sense in this case, so I propose instead that you implementation be complemented by: Object>>isSameSequenceAs: otherCollection ^false -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: sort: and sortBlock:
:-D when even the ANSI standard has a sort of "multiple inheritance" diagram to explain its collection hierarchy, you see this suffering is lingering for a long time behaving as some Lost characters. . .! all the possible puns intended by the author or to be discovered by more careful reading are there to be enjoyed and are not accidental1 Well, now that nanotraits and a figment to have something like a mixin in Squeak/Pharo is around the corner, who knows??!! -- Cesar Rabak Em 23/12/2009 16:28, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: > > That's probably why Stephane proposed a UniqueOrderedCollection: he > must have the expectation that this collection can be indexed in O(1) Not really :) I was more looking at the user perspective. You often want an orderedCollection (add:) vs Array at: but which deals with duplicate as a Set. I will rename it because OrderedSet is not a good name because this is not a Set. Now this is boring because this is not an OrderedCollection (or you do not have to be forced to implement insert:after:. I really see that the collection classes suffers from single inheritance and sometimes are too fat. A Nilish collection would be a fun exercise. May be we should start and get a cool OOPSLA paper out of that. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: hasEqualElements:
Em 23/12/2009 19:17, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com > escreveu: > 2009/12/23 Stéphane Ducasse : > > Ideally what I would like is > > > > = isSameSequenceAs: + same receiver kind (may be overkill) > > > > isSameSequenceAs: otherCollection > >"Answer whether the receiver's size is the same as > > otherCollection's size, and each of the receiver's > > elementsequalthecorrespondingelementof > > otherCollection." > > > > hasSameElements: > >"Answer whether the receiver's size is the same as > > otherCollection's size, and each of the receiver's > > elements is included in otherCollection and vice versa." > > Stef > > > like #(2 2 3) hasSameElements: #(2 3 3) -> true > but #(2 2 3) asSet hasSameElements: #(2 3 3) -> false Can someone illustrate this less enlightened coder what common programming pattern this wonderful method would of use for? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: hasEqualElements:
Igor, Sometimes a fallacy can be written by clever people, by accident. If you pay attention to the line: (size := self size) = otherCollection size ifFalse: [^false]. I all Smalltalks [Except Pharo to what I wrote a comment in issue 1637 http://code.google.com/p/pharo/issues/detail?id=1637] this would return false if self be not Collection or otheCollection isKindOf: Collection not. This happens because in these Smalltalks Object>>size returns zero. In Squeak where the method is implemented slightly different, an UndefinedObject>>size does return the zero for nil Objects but will raise an error for non indexable objects. So except if we are willing to have a very specific dialect of Smalltalk in Pharo, we'll probably have to fix the protocol for Object>>size, and then the line above will for most of the cases automatically return false as soon otherCollection happen to be isKindOf: Collection not. OTOH, if we keep Pharo as is, the above line will also by the automatism already described give the MNU as an error. . . -- Cesar Rabak Em 23/12/2009 20:22, Igor Stasenko escreveu: Eliot is right: the argument of isSameSequenceAs: should be already of SequenceableCollection kind , otherwise there is no sense asking , whether some collection has same sequence as another one, which probably not sequencable. By analogy, asking 'isSameColor: anObject' , we already stating, that an argument - anObject having a #color property. Otherwise, if its not, this should lead to error, but not returning 'false'. 2009/12/23 Eliot Miranda : > > > On Wed, Dec 23, 2009 at 10:41 AM, wrote: >> >> Em 23/12/2009 16:10, Eliot Miranda < eliot.mira...@gmail.com > escreveu: >> >> > >> > Core.SequenceableCollection comparing >> > isSameSequenceAs: otherCollection >> > >> > "Answer whether the receiver's size is the same as otherCollection's >> > size, and each of the receiver's elements equal the corresponding >> > element of otherCollection." >> > >> > | size | >> > (size := self size) = otherCollection size ifFalse: [^false]. >> > 1 to: size do: [:index | >> > (self at: index) = (otherCollection at: index) ifFalse: [^false]]. >> > ^true >> > >> > i.e. trust the caller is providing a sequence and if >> > otherCollection doesn't implement at: there will be a run-time >> > error, hence any otherCollection isKindOf: SequenceableCollection is >> > just wasted cycles. >> > >> >> I don't think that "trusting the caller" makes sense in this case, so >> I propose instead that you implementation be complemented by: >> >> Object>>isSameSequenceAs: otherCollection >> ^false > > We're talking about the argument otherCollection not the receiver. i.e. > leaving out isKindOf: in > isSameSequenceAs: otherCollection > "Answer whether the receiver's size is the same as > otherCollection's size, and each > of the receiver's elements equal the corresponding element of > otherCollection." > > | size | > (otherCollection isKindOf: SequenceableCollection) ifFalse: > [^false]. "this is a horrible wart" > (size := self size) = otherCollection size ifFalse: [^false]. > 1 to: size do: [:index | > (self at: index) = (otherCollection at: index) ifFalse: > [^false]]. > ^true > You could use double dispatching: > SequenceableCollection>>isSameSequenceAs: otherThing > ^otherThing isSameSequenceAsSequence: self > SequenceableCollection>> isSameSequenceAsSequence: aSequenceableCollection > aSequenceableCollection size ~= self size ifTrue: [^false]. > etc > Object isSameSequenceAsSequence: aSequenceableCollection > ^false > but I think in this case it's overkill. >> >> -- >> Cesar Rabak >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] SUnit forked, gofer it
Is this by accident or was by design? It seems too convoluted this mouse pointer modality plus some specific key combination. . . Em 23/12/2009 22:23, Tudor Girba < tudor.gi...@gmail.com > escreveu: It should work if your mouse is over the methods pane. Cheers, Doru On 24 Dec 2009, at 00:41, Mariano Martinez Peck wrote: > > > On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba > wrote: > In the current OB browser(s), if you press Command+T on a selected > test method runs only that test. > > > Are you sure ? If it press cmd + t over a test method, it is not > executed only that method but also all the rest test methods of that > class. I am trying 10496 dev with OBSystemBrowserAdaptor. I have > checked again just in case but still have that behaviour. > > Cheers > > Mariano > > Cheers, > Doru > > > On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote: > > > > > > > On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn > > wrote: > > Mariano Martinez Peck writes: > > > > > Sorry for go a bit offtopic, but is it possible to run only ONE > > test from the > > > browser??? I would like to right click on a test method and be > > execute. > > > Just like the "run tests" option but only for THAT test and not > > all the tests > > > of that class. Is that possible ? > > > > Fixed in my image. > > > > If you file a bug report, I'll attach the fix :) > > > > Excellent > > > > http://code.google.com/p/pharo/issues/detail?id=1665 > > > > Let me say that I really like all the little improvements that are > > being done. > > > > Cheers, > > > > Mariano > > > > > > --AA > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Reasonable is what we are accustomed with." ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: hasEqualElements:
Em 23/12/2009 22:51, Nicolas Cellier escreveu: > 2009/12/24 : > > Igor, > > Sometimes a fallacy can be written by clever people, by accident. > > If you pay attention to the line: > > (size := self size) = otherCollection size ifFalse: [^false]. > > I all Smalltalks [Except Pharo to what I wrote a comment in issue > > 1637 http://code.google.com/p/pharo/issues/detail?id=1637] this > > would return false if self be not Collection or otheCollection > > isKindOf: Collection not. > > This happens because in these Smalltalks Object>>size returns > > zero. > > > Not so sure. Try 1.0 size, then 1.0 at: 1.0 size in you favourite > dialect. Nicolas, In Squeak 3.10.2-7179: 1.0 size -> 2 "OK I'm surprised here" 1.0 at: 1.0 size -> 0 "this will not work anymore in Pharo because indices have to be Integer in Pharo right now" HTH -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: hasEqualElements:
Em 24/12/2009 01:21, Levente Uzonyi < le...@elte.hu > escreveu: > On Thu, 24 Dec 2009, csra...@bol.com.br wrote: > > > Em 23/12/2009 22:51, Nicolas Cellier escreveu: > > > >> 2009/12/24 : > >>> Igor, Sometimes a fallacy can be written by clever people, by > >>> accident. If you pay attention to the line: (size := self size) > >>> = otherCollection size ifFalse: [^false]. I all Smalltalks > >>> [Except Pharo to what I wrote a comment in issue 1637 > >>> http://code.google.com/p/pharo/issues/detail?id=1637] this would > >>> return false if self be not Collection or otheCollection > >>> isKindOf: Collection not.This happens because in these > >>> Smalltalks Object>>size returns zero. > >>> Not so sure. Try 1.0 size, then 1.0 at: 1.0 size in you > >> favourite > >> dialect. > > Nicolas, > > In Squeak 3.10.2-7179: > > 1.0 size -> 2 "OK I'm surprised here" > It's not surprising since Float is a variable word subclass of > Number. :) > > > 1.0 at: 1.0 size -> 0 "this will not work anymore in Pharo because > > indices have to be Integer in Pharo right now" > The index is 2, so it will work. Btw, I wonder how pharo can force > Integer indices if the vm accepts Floats too. > Levente, In fact VM _does_ _not_ accept Floats as indices. There is a hack in Squeak code (which in fact contradicts the comment in the method) in the #at: methods that make a conversion from Number to Integer. If you comment that code out you'll see the VM #at: (via the primitive) will fail with Floats. -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Search squeaksource for all senders of a method?
I think we'll need to have squeaksource ported to Seaside to do this... my 0.019 -- Cesar Rabak Em 24/12/2009 02:16, Adrian Kuhn < ak...@iam.unibe.ch > escreveu: I would like search squeaksource for all senders of a method. How could this be done? How would I approach doing this? --AA ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Search squeaksource for all senders of a method?
Yes. . . Christmas eve here so my reasoning is being impaired a little bit :-) []s -- Cesar Rabak Em 24/12/2009 15:29, Mariano Martinez Peck < marianop...@gmail.com > escreveu: On Thu, Dec 24, 2009 at 6:10 PM, wrote: I think we'll need to have squeaksource ported to Seaside to do this... I think squeaksource is already done with seaside. Did you wanted to say gemstone ? my 0.019 -- Cesar Rabak Em 24/12/2009 02:16, Adrian Kuhn < ak...@iam.unibe.ch > escreveu: I would like search squeaksource for all senders of a method. How could this be done? How would I approach doing this? --AA ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: hasEqualElements:
I've put some comments in the issue #1685. Em 25/12/2009 08:02, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: thanks for the explanation. I will add this in the method comment and probably class comment http://code.google.com/p/pharo/issues/detail?id=1685 Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] moose collection extensions
I find a lot of them awesome. However I would like to point out that in order these additions to make a difference they'll need to be spread the information as early as we can, so even in PBE we need to have a corner to address these "extensions/additions", otherwise they'll become curiosity for a lot of Pharoers. . . my 0.019... -- Cesar Rabak Em 27/12/2009 14:26, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: hi here are the collection extensions we use in Moose. I copied them to PharoTaskForces so that we can discuss and tweak the code if wanted. My favorite is flatCollect:/flatCollectAsSet: groupedBy: There are really useful. Stef [snipped] ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo-beginner mailing list ?
I come a little late for comment (hard day :-( ) so, I'll take profit of Stef's remarks to bring up an ancillary question to the group. Letting out the humble inclusions of a lot of hot shot programmers as "beginners" and trying this from a Requirements Elicitation exercise: What will we consider a *beginner*? People that never learned a programming language and need tutoring in basics? People that know other programming languages? Being so shall separate the efforts to teach the ones that know OO from the ones are knowledgeable in procedural ones¹? People already knowing Smalltalk but new to Pharo? I feel that in addition to mailing list (and perhaps newsgroup), we should assemble a CMS for spreading the basics and using the features of the system to direct prospective users according to their needs/wishes. my 0.01 -- Cesar Rabak [1] This angst was triggered attending to a speech in Smalltalks 2009 Em 30/12/2009 10:42, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Ok (we are all beginners :) at least I'm :) ). On Dec 30, 2009, at 1:35 PM, George Herolyants wrote: > Hi > > Maybe it would be better to name it pharo-user(s) and leave this list > for the developers of pharo? Because "beginner" has too narrow > meaning. > > > George > > 2009/12/30 Stéphane Ducasse : >> Hi all >> >> I remember that the squeak-beginner mailing-list (our ideas) was a huge >> success >> since it enabled people to ask questions and have less mails. >> So a question to you: do you think that it would be good to have a >> pharo-beginner mailing list? >> >> Stef >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo-beginner mailing list ?
I _think_ it is a lot of hours of work. Once the mailing list starts, we'll to monitor it. With some periodicity we should assemble a FAQ, also because the proper nature of the list it is possible incorrect advice be posted by other members and we need to monitor and suggest the correct content as well. Thinking in retrospect I believe this should be launched when we have Pharo 1.0 released and we can stabilize documentation, procedures, etc. my 0.01... -- Cesar Rabak Em 30/12/2009 14:16, Mariano Martinez Peck < marianop...@gmail.com > escreveu: +1 I would create it. It is not more than 1 hour or so of work. We don't loose nothing. Only the time will say if this was a good idea or not :) On Wed, Dec 30, 2009 at 5:07 PM, Miguel Cobá wrote: +1 Its ok to separate the development of pharo from the use/promotion/welcome to Pharo. Just don't let this become a mess with dozens of lists with a couple of posts each. This won't help Pharo cohesion in the long term. Miguel Cobá On Wed, Dec 30, 2009 at 5:41 AM, Stéphane Ducasse wrote: > Hi all > > I remember that the squeak-beginner mailing-list (our ideas) was a huge > success > since it enabled people to ask questions and have less mails. > So a question to you: do you think that it would be good to have a > pharo-beginner mailing list? > > Stef > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. . .
Em 30/12/2009 17:50, Bart Gauquie < bart.gauq...@gmail.com > escreveu: > I highly agree also !! > Its related to Pharo for Professional Development thread I started > 2 weeks ago. It basically says the same. My gut feeling is still > that stability should be the number one focus. Its great to > innovate, but innovation must not harm stability. > For me stability is keeping regression bugs to a minimum. To test > the stability of the GUI/Morphic parts of Pharo, I started to create > a little project: http://www.squeaksource.com/MorphicsRecordNPlay/. > This can record mouse events and replay them afterwards. My idea was > to take this as a sort of automated integration testing of Pharo. > You can then record all kinds of stuff: opening a browser, clicking > on a class, try every option out, ... . I've also attempted to > automatically convert these recordings into sunit test cases so they > can be automatically replayed, but I stumbled upon following > limitation: Long method can not be compiled using #compile: > aString. Haven't looked into it further yet. Any ideas here how > these can be replayed? Bart, Can't you store the events in a collection and run them iterating over the collected events instead of attempting to compile all them at once? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Developer guide ... ?
Bill, I think you nailed it precisely! Although all 'systems' working in Pharo will not be enough if we cannot connect and integrate with the leading technologies that we cannot afford to displace/emulate/write in Pharo smalltalk. -- Cesar Rabak Em 30/12/2009 22:54, Schwab,Wilhelm K escreveu: Levente, I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Developer guide ... ?
Bill, Perhaps what I wrote wasn't so clear and I thought I'd put a context when I commented that my ramblings were not about the 'systems' parts which is how I see your observation, and I agree on that. In fact, save some specifics which a plugin makes sense, probably doing in Smalltalk could make the platform more competitive and not only another 'weird syntax' for gluing some other's else libraries. Now, what I was thinking about we have not resources is the big echo systems we need to connect to, for example large packages (ERP/CRM systems), nowadays a hot subject is "Sharepoint integration" but there many others. I believe we should not attempt to write competitive replacements for these as we don't have the resources (not only technical but marketing as well). -- Cesar Rabak Em 31/12/2009 00:17, Schwab,Wilhelm K escreveu: Cesar, Sometimes rewriting is exactly the right thing to do. For example, Object Arts wrapped the Microsoft XML library. First, there is the question of untrusted input and MS binaries (yikes!!!), but also, any time bad input went into it, it would fire off an error with no indication of where it got into trouble. For some reason, MS did not think to take an IStream pointer that would have allowed one to check the position. For an http client, OA again wrapped MS binaries, complete with the typical punishing timeouts under MS control, and being hobbled if IE had been set (or set itself) to work offline. Dolphin is a wonderful product, but users would have been better served with home-grown code in those cases. Bottom line: I think we should rewrite when it makes sense to do so, and wrap just about anything that makes sense for interoperability. Clearly there is a lot to wrap, and priorities must be set, as it will often fall on an individual to do the dirty work. SSL is a no-brainer. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of csra...@bol.com.br Sent: Wednesday, December 30, 2009 8:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? Bill, I think you nailed it precisely! Although all 'systems' working in Pharo will not be enough if we cannot connect and integrate with the leading technologies that we cannot afford to displace/emulate/write in Pharo smalltalk. -- Cesar Rabak Em 30/12/2009 22:54, Schwab,Wilhelm K escreveu: Levente, I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo-beginner mailing list ?
Janko, As in Smalltalk we really care about names, I vote for maintaining the name "project" as the intended audience of this list is to gather developers and early users so even who has less skill or inclination to do coding can contribute with suggestions and bug reports. my 0.01 -- Cesar Rabak Em 31/12/2009 05:48, Janko Mivšek escreveu: Hi guys! Maybe it could be good idea to rename this list to pharo-dev? pharo-user, pharo-dev, a perfect balance in name and content :) Best regards Janko On 30. 12. 2009 18:46, Stéphane Ducasse wrote: > ok let us wait to get more feedback on the idea... > > Stef -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and rep lace in String
This brings to the forum an interesting debate! Clearly Levente's solution is the String redirection for Lukas' solution. Do this method eases programming for newcomers? Or it creates burden as presented in Stan's posting? AK is IIUC very knowledgeable of tools used in Squeak/Pharo and even though, had difficulty to find this particular method!! my 0.01... -- Cesar Rabak Em 31/12/2009 14:45, Levente Uzonyi escreveu: On Thu, 31 Dec 2009, Lukas Renggli wrote: >> Anyway, the +10 bounty for a regex solution is still open! > > 'bar' asRegex copy: 'foobarqux' replacingMatchesWith: 'XYZ' Or: 'foobarqux' copyWithRegex: 'bar' matchesReplacedWith: 'XYZ' Levente > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.
Em 31/12/2009 15:09, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: > Stan > My point is not to discourage you. :) Documentation is a state of > mind and a large valuable job. Now we can do the same as you said > (a guy ask and the others try to answer and we write comments that > are pushed into the system). > A first step is > - make a list of the classes that are missing comments: ++---+---+ | Image | update|missing| || |comment| ++---+---+ |1.0-dev | 10502 | 1831 | ++---+---+ |1.1-core| 11098 | 703 | ++---+---+ | 1.1-dev| 11098 | 1795 | ++---+---+ > - pick one aweek and via the mailing-list make it better and after > - we integrate it. > First it would be fun and we would get one class commented at the > end of the week. HTH -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and replace in String
Em 31/12/2009 15:52, Adrian Kuhn escreveu: > > > > This brings to the forum an interesting debate! Clearly Levente's > > solution is the String redirection for Lukas' solution. > > Do this method eases programming for newcomers? Or it creates > > burden as presented in Stan's posting? > > AK is IIUC very knowledgeable of tools used in Squeak/Pharo and > > even though, had difficulty to find this particular method!! > Good point! > To replace parts of a string, I want to send a message to the > string not to the > regex. So without doubt, string should understand such a > messages. (I dont know to which posting of Stan you're referring > though). OK, so the redirection of the messages to String makes sense. I would only gripe about the protocol it appears right now: *vb-regex is the _implementation_ of the method's functionality, but from a [programer] user POV it would be more likely to another one (perhaps "searching and replace"). > Also, I would expect short message names for common > operations. Alas none of > > #copyWithRegex:matchesReplacedWith:asRegex+ > ##copy:replacingMatchesWith: copyReplaceAll:with: > is particular short. And to make things words, none of these shows > up when auto > completing #repl... because they all start with copy. Plus strings > are nested in such a deep hierarchy that reading all understood > messages won't scale. Alas, I normally stay away of these discussions because I'm intoxicated by other programming idioms (like sed/AWK/Perl/Python/Ruby) which uses a very compact syntax for these operations and are now a lingua franca. > Personally, I would love to have a #gsub:with: on String. It is > short and uses established vocabulary. Yes it would be an adaptation of the above idioms to Smalltalk. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.
Em 31/12/2009 16:07, Stan Shepherd < stan.shepherd...@gmail.com > escreveu: > csrabak wrote: > > > > [snipped] > > > for info, I ran code critics on Lukas's quasi-release > http://www.seaside.st/distributions/Seaside-3.0a5.app.zip which is > essentially web dev without O2 I believe. (Code critics I can't get > to work in web dev) > Taking out spelling, there are about 3 items flagged, of which > 4802 long methods. > In an ideal world, it would be nice if the whole image passed code > critics. I think that for starters we should put efforts in having this state of "cleanness" in the core image first! > > > - pick one aweek and via the mailing-list make it better and > > - after we integrate it. > Well the one that's entertaining me at the moment is JSObject, but > I imagine people would rather start with a core class?. Stan, Notwithstanding the truth of you assertion, I maintain that every effort it the right direction is a worthy contribution! -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.
+1 Em 31/12/2009 16:30, Adrian Lienhard < a...@netstyle.ch > escreveu: What about using a wiki to gather and edit comments (as suggested by Stan) and then integrate them in a second step so that they are kept together with the code (as suggested by Stef)? Just a thought... Cheers Adrian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.
Adrian, This is a problem of simple solution: volunteer to convert the LaTeX PBE book to HTML and find a place to host it! my 0.01... -- Cesar Rabak Em 01/01/2010 03:47, Adrian Kuhn < ak...@iam.unibe.ch > escreveu: Schwab,Wilhelm K writes: > This sounds like a great way to augment documentation, but I still like class > and method comments - Stef might want to work on the train :) Various things > mentioned here recently (such as threading) will hopefully get chapters in > PBE. My (general) problem with book chapters is that they are not googlable. For example the awesome chapter on how exceptions work that was sent around on this list some time ago. Nobody will *ever* gonna stumble upon that chapter when googling (or binging, et cetera) for "exceptions smalltalk". OTOH, when I write a blog post it is indexed within 2 minutes! --AA ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
Em 04/01/2010 06:24, Mariano Martinez Peck < marianop...@gmail.com > escreveu: > Please, don't say "NO!" immediately. Read the mail carefully, > take a deep breath and think cold. > After working a couple of weeks in the Metacello configurations and > now with Damien's scripts to build Dev and Web images, I came to the > question: Do we really need a PharoWeb image? > I will give just my opinions of why having PharoWeb images is not > a good idea anymore [snipped] On the whole I appreciate and agree with the reasoning. > > Here is my proposal: > 1) Completely remove the idea of PharoWeb image. Remove the links > from the website and do not create Web images any more. +1 > 2) In http://www.pharo-project.org/pharo-download add a description > explaining that now Seaside images are based in Pharo, so you can > directly download that image. We can even explain a bit about > seaside, and even if you want you can put a href called "PharoWeb" > which links to the seaside image. However, I would rather call it > "PharoSeaside". I think here we have to work hard to stress this fact since IIUC the /pièce de résistance/ for Pharo is having all production work done by Seaside. > 3) Tomorrow we can have AidaWeb images based in > pharo (please Janko!!) so we can just do the same and put the link > to those images. While I'm fond of the idea on having AidaWeb very soon as possible, I also think we should put ourselves in Janko's shoes and understand that he'll need to master Metacelllo to arrive at the packaging. . . > 4) You may notice that Seaside images are a bit "different" than our > Dev images. This is mostly due to the preferences, the theme and > maybe some tools (ECompeltion instead of OCompletion, etc..). So, > what I suggest is to prepare a little script that can be > downloadable and those people who want a Seaside image but more > "similar" to our Dev images, just run that script. I would postpone the publishing of these kind of scripts for a much more stable Pharo and Metacello (or packaging solution ensuing), otherwise you'll have the same work as testing the scripts means creating and testing the packages!! > > So...what do you think? I would really like to hear your opinion > about this. my 0.0199 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About moving tmp closer their use
Stef, I think that the issue on "readibility" is in the eyes of the beholder (a.k.a. zealot /du jour/). From a cognitive POV having the variables 'created' and used as near as possible should make the code more understandable than having them all declared at the top of the method and used only (say as a temp variable within a block [worse if the variable is used as temp in two blocks...]). These issues (on readibility) are less strong in Smalltalk than other languages because ST is dynamic typed and the declaration is more often than not just the name of the variable. Also, ST promotes the creation of short methods and in the average we should be able to see more or less the same way the declaration of a variable be it at the top of the method or inside a block. OTOH, while the reality still strikes us with several large methods, then the ideas of having the declaration as near of the as possible are IMO a good move. my 0.01... -- Cesar Rabak Em 04/01/2010 10:42, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and replace in String
Em 06/01/2010 11:18, Adrian Kuhn < ak...@iam.unibe.ch > escreveu: > Douglas Brebner writes: > > > Please bear in mind that natural languages have much more > > redundancy and less precision than programming languages. > You are right! > Personally I believe programming languages should strive to be as > close to the > the more stringent English of specification documents, and not to > natural language with *all* its facets. The main line of > argumentation in my previous mail was thus that the very argument > of natural languages can be used in favor of my point as well :) > > > In addition, programming languages have handy tools like > > autocompletion that natural languages don't, making abbreviations > > less useful :) > That argument keeps popping up (eg from Ramon just in parallel to > this > answer, and also before) but I am not sure if auto completion is > the whole story. For example in Object-C you have to write > > @"hello " stringByAppendingString: @"worlds!" > > to concatenate strings. Whereas in Smalltalk we just write > > 'hello ', 'worlds!' > > clearly both are as writable when you got auto completion, but > isn't the second just more readable? Two points on "more readable". _Right now_ to Smalltalkers that know by heart that #, is a concatenation operator, it seems *less cluttered* and thus it appears more readable. Put forward some twenty to fifty years (or to do it right now ask a girlfriend that doesn't know nor Objective C nor Smalltalk) to see what of two expressions convene more meaning. As everybody else knows :-P the string concatenation operator is '+', right!? So #, needs to be explained anyway. . . > In his "Elements of Style" > William Strunk recommends to omit unnecessary word. With regard to > source code, I'd say the lesson should be that more verbose is > typically more readable but *not* always. > So given this observation that sometimes operators (or single > letters, which > for that sake the same) are *sometimes* more readable than natural > language, we can go an revisit the set of operators in Smalltalk > and check if there might be more candidates. And I'd be more than > surprised if are were not some more candidates for abbreviation. > For example Pharo already got #<< for appending to a stream, so the > same would > make sense to append elements to a collecton, such that we can > write > > list := List new << 'lorem' << 'ipsum' << 'dolor'. > et cetera. This may lead to the same problem we already have with #, namely it is slow and not recommended for repeated operations. We have to strike a balance between the easiness for writing the code with the implementation that will run it. my 0.01 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Dev images with or without tests?
Alexandre, Once upon a time I thought like you, but I changed my mind when I realized that more and more the tests are being engineered in such a fashion that using them for the sake of an example is becoming convoluted. As we create all the machinery (setup and tear down) to do Unit Tests the test itself conveys less information unless you start to navigate the SUnit land, and I feel it will become even more inexpugnable for newcomers as soon PhExample enters the scene (you might have chained tests). Notwithstanding the accepted notion that tests are a form of documentation, I would say more and more they're falling into the same slot of the argument "you have access to the code": true but not practical for the day to day chores. -- Cesar Rabak Em 06/01/2010 14:58, Alexandre Bergel < alexan...@bergel.eu > escreveu: It is more for having examples under hands. Cheers, Alexandre ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and rep lace in String
Em 06/01/2010 17:30, Levente Uzonyi < le...@elte.hu > escreveu: > On Wed, 6 Jan 2010, csra...@bol.com.br wrote: [snipped] > > As everybody else knows :-P the string concatenation operator is > > '+', right!? So #, needs to be explained anyway. . . > You're wrong, it's '.'. :) You know this polyglot approach to programming ends up with some confusion :-) [snipped] > > This may lead to the same problem we already have with #, namely > > it is slow and not recommended for repeated operations. > > > No, it's fast, because it doesn't create copies. Of course to know > that you also have to know that List is an alias for > OrderedCollection... It's just a C++ism that makes your code > slower. :) > Levente, In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there is no List class, and: Collection>>, aCollection ^self copy addAll: aCollection; yourself Which creates copies for each #, method send, right? Or do I miss something here? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and rep lace in String
Em 06/01/2010 22:06, Levente Uzonyi < le...@elte.hu > escreveu: > On Wed, 6 Jan 2010, csra...@bol.com.br wrote: > > > Em 06/01/2010 17:30, Levente Uzonyi < le...@elte.hu > escreveu: > > > >> On Wed, 6 Jan 2010, csra...@bol.com.br wrote: [snipped] > >>> As everybody else knows :-P the string concatenation operator is > >>> '+', right!? So #, needs to be explained anyway. . . > >> You're wrong, it's '.'. :) > > You know this polyglot approach to programming ends up with some > > confusion :-) > > [snipped] > > > >>> This may lead to the same problem we already have with #, namely > >>> it is slow and not recommended for repeated operations. > >>> No, it's fast, because it doesn't create copies. Of course to > >> know > >> that you also have to know that List is an alias for > >> OrderedCollection... It's just a C++ism that makes your code > >> slower. :) > >> Levente, > > In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there > > is no List class, and: > > > > Collection>>, aCollection ^self copy addAll: aCollection; yourself > > Which creates copies for each #, method send, right? Or do I miss > > something here? > Yes you do, List is one of Adrian's ideas to Huffman code > smalltalk.Details here > http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/ > Ok Levente! In this case after reading Adrian's blog post, I would say "List" is not a good choice: VW uses List for a different kind of object (a descendant from OrderedCollection, in fact). As a side note, IMNHO Object>>out (as Travis' idea) seems to me better than Object>>p for the same purpose. Regards, -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Nanosecond-level profiling in Pharo?
I don't want to rain in your folks party, but a nanosecond is a millionth of a millisecond. Also, it is at the timing of silicon memory access on present microcomputers. Isn't enough you increase the accuracy of the timing by one thousand looking for a solution to get *microsecond* resolution? HTH, -- Cesar Rabak Em 07/01/2010 20:57, Alexandre Bergel < alexan...@bergel.eu > escreveu: Ok, good to know. Thanks Igor, Alexandre On 7 Jan 2010, at 19:29, Igor Stasenko wrote: > 2010/1/7 Alexandre Bergel : >> Hi! >> >> I am currently working on a new profiler for Pharo. The idea is to >> graphically renders a profiling using Mondrian. I hope to release it >> soon. >> When discussing with an expert in the field (Walter Binder), the >> question about time grain was raised. I am partly based on >> MessageTally, which has a millisecond grain. Anyone is aware of a >> finer grain? At the level of nanosecond? Does it makes sense since >> there is no JIT (yet)? >> > > AFAIK, there's no primitives in VM, which provide timing with > nanosecond precision. > > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Nanosecond-level profiling in Pharo?
Do you have information if the "level" is resolution only or effective accuracy? I got curious on this! -- Cesar Rabak Em 08/01/2010 15:56, Alexandre Bergel < alexan...@bergel.eu > escreveu: This is the level of state-of-the-Art Java profilers operate with. Cheers, Alexandre On 8 Jan 2010, at 14:48, csra...@bol.com.br wrote: > I don't want to rain in your folks party, but a nanosecond is a > millionth of a millisecond. Also, it is at the timing of silicon > memory access on present microcomputers. > > Isn't enough you increase the accuracy of the timing by one thousand > looking for a solution to get *microsecond* resolution? > > HTH, > > -- > Cesar Rabak > > > > Em 07/01/2010 20:57, Alexandre Bergel < alexan...@bergel.eu > > escreveu: > > > Ok, good to know. > > Thanks Igor, > Alexandre > > > On 7 Jan 2010, at 19:29, Igor Stasenko wrote: > >> 2010/1/7 Alexandre Bergel : >>> Hi! >>> >>> I am currently working on a new profiler for Pharo. The idea is to >>> graphically renders a profiling using Mondrian. I hope to release it >>> soon. >>> When discussing with an expert in the field (Walter Binder), the >>> question about time grain was raised. I am partly based on >>> MessageTally, which has a millisecond grain. Anyone is aware of a >>> finer grain? At the level of nanosecond? Does it makes sense since >>> there is no JIT (yet)? >>> >> >> AFAIK, there's no primitives in VM, which provide timing with >> nanosecond precision. >> >> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] System -> About in Dev images
Em 10/01/2010 13:04, Mariano Martinez Peck < marianop...@gmail.com > escreveu: > On Sun, Jan 10,2010 at 3:38 PM, Michael Roberts > wrote: > > 2010/1/10 Mariano Martinez Peck : > [snipped] > > > >> and you can change the suffix as well, but personally i would > >> not use the date in the image name. > >> > > For the date you refer to year, month and number of version > > inside the month ? > > yes I think it is too complicated a version scheme. The dev tag is > also synonymous with Pharo. > so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I > would call it Pharo-1.0-10505-rc1. This is the same scheme that the > core image uses, and Pharo 1.1 will have this behaviour already > using #imageVersionString since it is in 1.1. > > > That's cool. I evaluate: > SystemVersion current version: 'Pharo-1.0-10505-rc1' > And seems to be almost what I want. It would be cool (maybe not > for 1.0, but for 1.1) if we can see not only the version of Pharo, > but also opf the pharoCore...So, SystemVersion could understand: > coreVersion: and version: > Then in System -> About, if I am in a core image I would see: > > PharoCore1.0rc1 > Latest update: #10505 OK. > And if I am in Pharo I would see > Pharo1.0-10505-rc1dev10.01.1 Isn't this ^ completely redundant with: > PharoCore1.0rc1 > Latest update: #10505 <--- this? -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Allow or disable System Update in PharoDev images ?
Can't it be left as user setting that can be selected ('decided') after
downloading the image?
--
Cesar Rabak
Em 10/01/2010 13:45, Mariano Martinez Peck < marianop...@gmail.com > escreveu:
It is a simple question. Do we allow that or not. Miguel wrote the pros and
cons:
Pros
- Can fix bugs after release
- Can aply improvements to the image after release.
Cons
- Can mess the image of someone by overwriting some overridden method.
- Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] System -> About in Dev images
Em 10/01/2010 17:46, Mariano Martinez Peck escreveu: > On Sun, Jan 10, 2010 at 8:37 PM, wrote: > Em 10/01/2010 13:04, Mariano Martinez Peck > escreveu: > > > > PharoCore1.0rc1 Latest update: #10505 > > OK. > > > > And if I am in Pharo I would see > > Pharo1.0-10505-rc1dev10.01.1 > Isn't this ^ completely redundant with: > > > PharoCore1.0rc1 Latest update: #10505 <--- this? > > > the problem is what I have already said. If the user did a system > update, the core will be higher that the dev image, and not the > same. I'm not so sure if I undertand this in full, so I'll test my understanding: Do your assertion above means that an hypothetical: Pharo1.0-10505-rc1dev10.01.1 that after some updates ends up reponding in System->About this: Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510 You say that it would be *different* than a brand new downloaded: Pharo1.0-10510-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510 Is it? > Maybe we can just don't care about this case or disable the system > update in dev as we are discussing in another thread. As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need. -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo for Professional Development
Given we're at the start of the year, I can still have wishes as well, then let's add Gayvert's wxWidgets as well http://www.wxsqueak.org/ []s -- Cesar Rabak Em 11/01/2010 05:18, Stéphane Ducasse < stephane.duca...@inria.fr > escreveu: Now for pharo people could ressurect the GTK port done by gwenael. Or pay for that. Stef On Jan 11, 2010, at 2:40 AM, Stephen Taylor wrote: > Schwab,Wilhelm K wrote: >> Dolphin is better than that > > I've put my money where my mouth is with Dolphin - I think I've bought > every product they've ever released, just to give them a hand - despite > the fact that I've still got a Dolphin version4 image on the go! > > >> The feature you are describing is what they call an idea space, and it is >> probably my least favorite features of Dolphin. > > And one of my favourites! If only everyone agreed with me all the time... > > >> Bill > > > Steve > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Object Buffer (implementation tryout) -- about keyboard shortcuts
May I suggest that instead of having new tools assigned shortcuts hard coded we go after some solution to have them configurable? my 0.01 -- Cesar Rabak Em 11/01/2010 15:56, Alexandre Bergel escreveu: Maybe you can also add shortcuts: Shift-Cmd-c, Shift-Cmd-v Alexandre On 11 Jan 2010, at 14:45, Cédrick Béler wrote: > Here is the screenshot... > > ps: there is a small bug for explorer in the version I sent. I fixed > it but don't send yet > -- > Cédrick > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Object Buffer (implementation tryout)
On this line of reasoning, in Windows there used to exist a small utility called "Clipboard Viewer" that allowed the OS clipboard to be inspected and some of the 'things' (to avoid the clash with Objects from OOA/OOD/OOP) could be 'seen' in more than a single way. -- Cesar Rabak Em 11/01/2010 16:18, Gary Chambers < gazzagu...@btinternet.com > escreveu: Perhaps a unified clipboard would be nicer... objects or text (or, potentially converible to host OS things...). A similiar approach has worked well for our ReportBuilder (guess what, it is called ObjectClipboard...). Nothing especially special about an object, just another kind of thing that can be pasted where allowed... Regards, Gary - Original Message - From: "Alexandre Bergel" To: Sent: Monday, January 11, 2010 5:56 PM Subject: Re: [Pharo-project] Object Buffer (implementation tryout) Maybe you can also add shortcuts: Shift-Cmd-c, Shift-Cmd-v Alexandre On 11 Jan 2010, at 14:45, Cédrick Béler wrote: > Here is the screenshot... > > ps: there is a small bug for explorer in the version I sent. I fixed > it but don't send yet > -- > Cédrick > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
