January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] does anybody knows who is using StandardToolSet?

by Mariano Martinez Peck

yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it. http://code.google.com/p/pharo/issues/detail?id=1915 On Fri, Jan 28, 2011 at 10:44 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Because it would be good that it uses a registration mechanism. > Hardcoding the classes of the tools is not optimal for example for the new > Finder. > > Stef >

Jan. 28, 2011

Re: [Pharo-project] Issue 3618 in pharo: logError: aString inContext: aContext to: is used and it is deprecated

by pharo＠googlecode.com

Comment #1 on issue 3618 by gazzagu...(a)googlemail.com: logError: aString inContext: aContext to: is used and it is deprecated http://code.google.com/p/pharo/issues/detail?id=3618 Also, (self class context: aContext) should just be (self context: aContext) Additionally, the ErrorRecursion maybe should be set before the first lines, I am unable to load updates due to recursion (via the deprecation)... Perhaps this is all now horribly broken...

Jan. 28, 2011

Re: [Pharo-project] SimpleButtonMorph openInWorld

by csrabak＠bol.com.br

OTOH, For cases like that I think the best is to attribute the result of "SimpleButtonMorph new..." to a variable and the just use the message delete on this variable... my 0.019999... -- Cesar Rabak Em 28/01/2011 04:17, Fernando Olivero < fernando.olivero(a)usi.ch > escreveu: You can also evaluate the following expresions in a wokspace, SimpleButtonMorph allInstances do:[:each| each delete]. or | buttons | buttons := World submorphs detect:[:each| each isKindOf: SimpleButtonMorph ] . buttons anyOne delete. But i also prefer Serge option, because Morphs are directly manipulable for a reason! Fernando On Fri, Jan 28, 2011 at 2:49 AM, Serge Stinckwich wrote: > On Fri, Jan 28, 2011 at 9:40 AM, DAE wrote: >> This code makes a square button appear in the topleft corner >> >> Â Â Â Â SimpleButtonMorph new >> Â Â Â Â Â Â Â Â target: Smalltalk; >> Â Â Â Â Â Â Â Â label: 'Beep!'; >> Â Â Â Â Â Â Â Â actionSelector: #beep; >> Â Â Â Â Â Â Â Â openInWorld >> >> >> How do I make it go away? >> >> Sorry if I posted to the wrong group. Â If so, please tell me where is correct. > > On my macintosh, CTRL+ right mouse button > and select the delete item. > > Regards, > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > >

Jan. 28, 2011

Re: [Pharo-project] [squeak-dev] Accessing external resources in a cross-platform way

by HernÃ¡n Morales Durand

Thanks David, I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too 2011/1/28 David T. Lewis <lewis(a)mail.msen.com>: > On Fri, Jan 28, 2011 at 01:51:22PM +0100, Hern??n Morales Durand wrote: >> Let's say you want to resolve paths in a cross platform way >> >> Binaries @ 'MyExec' >> Libraries @ 'MyLib' >> SystemLibraries @ 'SystemLib' >> etc. >> >> then Binaries is >> >> In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) " >> and all standard locations including translations " >> In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations " >> etc >> >> Now you may say it is necessary to scan all directories to find >> MyExec, yes but you may then save that location >> >> myBinaryLocation := Binaries @ 'MyExec'. >> >> so you scan for it just once. >> >> What do you think? it is already implemented anywhere? >> If not what package do you think is more suitable or prepared for >> implementing it? > > Hern??n, > > This is of course very platform dependent, and it is more complex > than you might expect due to differences in file systems, operating > systems, volume names (windows), environment variables and search > path conventions. > > Both Windows and Unix use various seach paths accessible through > environment variables, and the conventions for this tend to change > over time with different OS versions. So it would probably be best > to rely directly on those environment variables for identifying > search paths. > > Aside from the conventions for default locations and search paths, > some of what you are looking for may also be implemented for Windows > and Unix in SqS/CommandShell in class ShellSyntax: > > Â My instances implement parsing of strings in a manner similar to > Â a simple Unix command shell. I provide path name expansion in the > Â context of an external file system, and support the syntax required > Â for IO redirection. All file name globbing and PATH searching are > Â implemented in Smalltalk rather than in C library functions or an > Â external command shell. > > Â Most of my syntax is applicable for any operating system. Where > Â needed, platform specific methods are in my "platform dependent" > Â category. Currently, Unix and Windows are supported, and other > Â platforms have not been tested. The primary difference between > Â Unix and Windows support is that device names (such as 'C:') are > Â used in Windows path strings. Separate current working directory > Â strings are maintained for all Windows device names. For Unix, > Â a single current working directory path is used. On Windows, > Â this permits the CommandShell 'cd' command to support changing > Â directories to another device without losing track of the current > Â working directory for the previous device. > > Â Command pipeline syntax is not supported here. See CommandShell > Â for the implementation of command pipelines. > > Dave > > >

Jan. 28, 2011

Re: [Pharo-project] Issue 3609 in pharo: Integrate RPackage

by pharo＠googlecode.com

Comment #2 on issue 3609 by tudor.gi...(a)gmail.com: Integrate RPackage http://code.google.com/p/pharo/issues/detail?id=3609 The decision in RPackage is to match categories 1-to-1 to packages. Thus, an RPackage will not have subcategories.

Jan. 28, 2011

[Pharo-project] Issue 3618 in pharo: logError: aString inContext: aContext to: is used and it is deprecated

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com CC: siguc...(a)gmail.com Labels: Milestone-1.3 New issue 3618 by stephane...(a)gmail.com: logError: aString inContext: aContext to: is used and it is deprecated http://code.google.com/p/pharo/issues/detail?id=3618 3 notifyLabel: 'foo' openContext: aContext label: aString contents: contentsStringOrNil "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger." <primitive: 19> "Simulation guard" ErrorRecursion not & self logDebuggerStackToFile ifTrue: [Smalltalk logError: aString inContext: aContext to: 'PharoDebug.log']. ErrorRecursion ifTrue:[ ErrorRecursion := false. self primitiveError: aString]. ErrorRecursion := true. self informExistingDebugger: aContext label: aString. (self class context: aContext) openNotifierContents: contentsStringOrNil label: aString. ErrorRecursion := false. Processor activeProcess suspend.

Jan. 28, 2011

Re: [Pharo-project] Issue 3611 in pharo: ParagraphEditor should be removed

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #2 on issue 3611 by stephane...(a)gmail.com: ParagraphEditor should be removed http://code.google.com/p/pharo/issues/detail?id=3611 No alain you will not have the fun to do it :)

Jan. 28, 2011

Re: [Pharo-project] Issue 3616 in pharo: SyntaxError listMenu: fixes

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3616 by stephane...(a)gmail.com: SyntaxError listMenu: fixes http://code.google.com/p/pharo/issues/detail?id=3616 (No comment was entered for this change.)

Jan. 28, 2011

Re: [Pharo-project] Issue 3617 in pharo: Hudson 1.2dev : ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3617 by jbaptist...(a)gmail.com: Hudson 1.2dev : ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy http://code.google.com/p/pharo/issues/detail?id=3617 (No comment was entered for this change.)

Jan. 28, 2011

[Pharo-project] Issue 3617 in pharo: Hudson 1.2dev : ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy

by pharo＠googlecode.com

Status: Accepted Owner: jbaptist...(a)gmail.com Labels: Milestone-1.1.2-DevImage New issue 3617 by jbaptist...(a)gmail.com: Hudson 1.2dev : ShoutTests.Parsing.SHParserST80Test.testCollectionHierarchy http://code.google.com/p/pharo/issues/detail?id=3617 If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: 1.2dev The SHParserST80 don't take in consideration some pragma (from VMMaker ) for example: - <inline:true> -<var:'asd' declareC:'void *'> And return a PragmaKeyword Value in collection hierarchy (ByteArray and Bitmap) I just fix the test Attachments: SHParserST80Test.st 14.7 KB

Jan. 28, 2011