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

Re: [Pharo-project] FileSystem inconsistency

by Jimmie Houchin

On 1/8/2013 11:18 PM, Yanni Chiu wrote: > On 09/01/13 12:05 AM, Jimmie Houchin wrote: >> >> Part of the problem is that I did not sufficiently read the >> documentation in the class comment. I also did not know of the PBE2 >> chapter referenced by Stef. > > I used to assume that class comments were empty. Nowadays, there is > often useful information there. Maybe the browser could indicate > whether or not the class comment is empty - something like '--?', when > the comment is empty. The Nautilus browser in Pharo 2.0 does distinguish these classes with an ! ClassName in the browser. Then you have to click on the Comments button to display the comment. I was just negligent to notice and read thoroughly. It might be nice if the these classes which have external documentation such as in the Pharo By Example, noted such. Jimmie

Jan. 9, 2013

Re: [Pharo-project] FileSystem inconsistency

by Jimmie Houchin

On 1/8/2013 12:14 PM, Camillo Bruni wrote: > On 2013-01-08, at 18:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol. >> maybe for 3.0? > yes definitely :). > > Jimmie, maybe you can open an issue on code.google.com/p/pharo/? > with a complete list of the methods you find confusing? I opened an issue on the basename usage at: http://code.google.com/p/pharo/issues/detail?id=7222 I wasn't really confused by anything in particular that I mentioned. Just noting what I saw as an inconsistency in a method name. The documentation that Stef referred to should help. I do like the 'MyPath' asFileReference method. What I have found confusing is the workingDirectory which is an instance variable. In a workspace I did the following. Initial workingDirectory fr1 := FileSystem disk workingDirectory. fr1. " file://C:\Users\Jimmie\Pharo\images" fs1 := FileSystem disk. fs1 workingDirectory." file://C:\Users\Jimmie\Pharo\images" New FileSystem instance fs2 := FileSystem disk. workingDirectory is the same as the first instance. fs2 workingDirectory." file://C:\Users\Jimmie\Pharo\images" Change workingDirectory on the new instance using the instance method #workingDirectoryPath: fs2 workingDirectoryPath: Path / 'C:\Users\Jimmie'. fs2 workingDirectory." file://C:\Users\Jimmie" First instance workingDirectory unchanged. fs1 workingDirectory." file://C:\Users\Jimmie\Pharo\images" New FileSystem instance. fs3 := FileSystem disk. workingDirectory is the same as the changed one on the second instance. fs3 workingDirectory." file://C:\Users\Jimmie" fs1 workingDirectory." file://C:\Users\Jimmie\Pharo\images" fs2 workingDirectory." file://C:\Users\Jimmie" New FileSystemDirectoryEntry instance has the new workingDirectory fr2 := FileSystem disk workingDirectory. fr2." file://C:\Users\Jimmie" What I don't understand is why using an instance method to change an instance variable, changes something in the class which affects the initial state of new instances. This was an unexpected behavior for me as I was operating on an instance variable via an instance method. At least so I thought. I may have overlooked such, but I haven't seen any documentation about this behavior. So I don't know if this is the desired behavior or if it is a bug. I was hoping for the workingDirectory to be an instance variable which could be different for each instance. It would be nice if a FileSystem object could be created with the desired workingDirectory. But I imagine that the proper way to do such is to rather create a FileReference to the desired directory and operate on it. Just curious. Jimmie

Jan. 9, 2013

Re: [Pharo-project] FileSystem inconsistency

by Yanni Chiu

On 09/01/13 12:05 AM, Jimmie Houchin wrote: > > Part of the problem is that I did not sufficiently read the > documentation in the class comment. I also did not know of the PBE2 > chapter referenced by Stef. I used to assume that class comments were empty. Nowadays, there is often useful information there. Maybe the browser could indicate whether or not the class comment is empty - something like '--?', when the comment is empty.

Jan. 9, 2013

Re: [Pharo-project] FileSystem inconsistency

by Jimmie Houchin

Thanks for all the suggestions for easier way to create references. Part of the problem is that I did not sufficiently read the documentation in the class comment. I also did not know of the PBE2 chapter referenced by Stef. Part of the problem is also that the browser in 2.0 is presenting things differently and I am not sure I understand fully what it is communicating. When I look at the class methods in FileSystem most of them are gray and a only few black. It is not self evident what the gray coloration means. Also when one clicks on instance creation, the only method is #store:. So unless you see the class comment, then you won't see the documentation on using FileSystem disk workingDirectory which returns a FileSystemDirectoryEntry instance, while FileSystem disk returns a FileSystem instance. I should have investigated documentation a little harder. Jimmie On 1/8/2013 11:01 AM, Esteban Lorenzano wrote: > anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol. > maybe for 3.0? > > On Jan 8, 2013, at 5:58 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> On 2013-01-08, at 17:55, Max Leske <maxleske(a)gmail.com> wrote: >>> On 08.01.2013, at 17:07, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>>> Hello, >>>> >>>> I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it. >>>> >>>> It took me a little while to learn to do something like: >>>> fs := FileSystem store: (DiskStore activeClass createDefault). >>> Why not >>> >>> fs := FileSystem disk. >>> >>> ?? >>> >>> or: >>> >>> reference := FileSystem disk referenceTo: '/foo/bar.txt'. >> or: >> >> '/foo/bar/plonk.txt' asFileReference >> '/foo/bar' asFileReference >> >> which creates a FileReference on the disk, the default

Jan. 9, 2013

Re: [Pharo-project] New Cog VMs available...

by Eliot Miranda

...and at http://www.mirandabanda.org/files/Cog/VM/VM.r2664. CogVM binaries as per VMMaker.oscog-eem.252/r2664. Issue 117. Fix primitiveRemLargeIntegers. The result should be negated iff receiver negative. On Tue, Jan 8, 2013 at 3:28 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > ...at http://www.mirandabanda.org/files/Cog/VM/VM.r2662/. > > CogVM binaries as per VMMaker.oscog-eem.251/r2662 > > Give primitiveRemLargeIntegers primitive # 20. > > Add yet another libc line to the linux launch script(s), and try and make > the > script suggest users extend it themselves. you can lead a horse to > water... > > Fix (old) bug in ssAllocateRequiredRegMask:upThrough: > that would flush entire stack if allocating any register. > > Implement absent receiver sends in the Newspeak Cogit. > > On Mac turn off inlining when compiling the Cogit. The Cogit's runtime is > negligible and we prefer to save space. With the recent changes (better > shift > code??) the VM appears faster anyway. > > Integrate directed shift changes from cog issue 111 that affect the > CoInterpreter and Cogit. > > Make the translated primitive plugins include info from their > primitive supplying classes. > > Integrate changes from VMMaker-dtl.293 which use >> & << shifts > in place of slower bitShift: code in plugins. > Add width failure cases to BMPReadWriterPlugin read & write 24Bmp prims. > > Integrate issue 115. Fix FFIPlugin/ThreadedFFIPlugin unsignedShortAt:. > > -- > Happy New Year everyone, > Eliot > -- best, Eliot

Jan. 9, 2013

[Pharo-project] Smalllint for Traits

by aizcorbe

Hi all, as part of a thesis I have been working on, I extended Smalllint to let it check Traits and Traits specific errors. The enviroment objects and the refactoring scope browsers now handles and list classes and traits (before they just handled classes). The new refactoring scope selection is available at "refactoring scope>selection all behaviors" menu option. The smalllint framework have been extended and is available at "refactor>code critics extended". These are some of the changes: smalllint rules can now check traits and traits methods. a new rule presentation schema is available, which lets to spot the place where the error is actually located and also add extra information to the rule result (but is more difficult to define the rules in this way). For extra information about the changes and how can they be used you can refer to: http://dc.uba.ar/inv/tesis/licenciatura/2012/aizcorbe.pdf (refer to chapter 4 if you want to bypass all the conceptual background ) there was also added some rules to check Traits specific errors. The Smalllint for Traits extension is available for pharo 1.3 and is located in: http://www.squeaksource.com/TesisTraitLint the packages are organized as follows: OBLintTraitExtension.1.3 (the smalltalk environment extension to add Traits handling capabilities). TraitLint.1.3 (the Smalllint extension itself and the Traits rules implementation). TraitLintTest.1.3 (the unit tests for the Smalllint extension and the rules implementation, it is not mandatory). I hope you find this useful. cheers -- View this message in context: http://forum.world.st/Smalllint-for-Traits-tp4662559.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 9, 2013

[Pharo-project] New Cog VMs available...

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r2662/. CogVM binaries as per VMMaker.oscog-eem.251/r2662 Give primitiveRemLargeIntegers primitive # 20. Add yet another libc line to the linux launch script(s), and try and make the script suggest users extend it themselves. you can lead a horse to water... Fix (old) bug in ssAllocateRequiredRegMask:upThrough: that would flush entire stack if allocating any register. Implement absent receiver sends in the Newspeak Cogit. On Mac turn off inlining when compiling the Cogit. The Cogit's runtime is negligible and we prefer to save space. With the recent changes (better shift code??) the VM appears faster anyway. Integrate directed shift changes from cog issue 111 that affect the CoInterpreter and Cogit. Make the translated primitive plugins include info from their primitive supplying classes. Integrate changes from VMMaker-dtl.293 which use >> & << shifts in place of slower bitShift: code in plugins. Add width failure cases to BMPReadWriterPlugin read & write 24Bmp prims. Integrate issue 115. Fix FFIPlugin/ThreadedFFIPlugin unsignedShortAt:. -- Happy New Year everyone, Eliot

Jan. 8, 2013

Re: [Pharo-project] UI blocked

by Paul DeBruicker

Nevin Pratt wrote > > For what it's worth, the UI blocking also happens occasionally (not very > often, > but occasionally) with Squeak 3.8/Seaside 2.8. But it's easy to unblock. > Just > run the "screenshot" app (within Seaside), then at the top there is a > "Suspend > UI Process" link. Click it to suspend, then click it again to unsuspend. > That > almost always unblocks the UI, although occasionally I have to suspend and > unsuspend a second time, not just once. > > But, because of the "screenshot" app is able to unblock it, the UI > blocking > problem has never been more than a minor inconvenience. > > Nevin This helped me out today. And if you've disabled all of the development tools you can get the screenshot app back by putting: WAScreenshot initialize. in a st file (e.g. startScreenshot.st) then on the command line doing squeak myFrozenImage.image startScreenshot.st then going to http://127.0.0.1:8080/tools/screenshot and clicking the stop/resume links. -- View this message in context: http://forum.world.st/UI-blocked-tp3930833p4662547.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 8, 2013

Re: [Pharo-project] Is there a simple example of how to create a GUI form in Pharo or Squeak?

by Frank Church

On 25 December 2012 14:48, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Hi, two good sources of information on GUI building are > > > http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html?utm_source=… > > > http://book.pharo-project.org/book/LanguageAndLibraries/GUI/?_s=yllsSvKBo5c… > > They're not that hard to find (if you are aware of the Collab book and the > pharocasts). > > You might want to check out Glamour also, > http://www.themoosebook.org/book/internals/glamour > > > Fernando > > > I am working my way through the Polymorph GUI demo and I at around 2:34 notice that the examples are not in my image. The demo is over 2 years old so the example packages may have been removed from recent versions of Pharo. Is there some way to get them back? Is there also some way to search the repositories to see if they contain package from Smalltalk? > On Mon, Dec 24, 2012 at 11:22 AM, Frank Church <vfclists(a)gmail.com> wrote: > >> Is there a simple example of how to create a GUI form in Pharo or Squeak? >> >> I want to accomplish a simple task with a form: >> >> 1. Create a form with a button and edit control and 2 text areas. >> >> 2. Enter a value into the edit control. >> >> 3. Run a database query using the value in the edit control as a >> parameter and return the results in text area 1 >> >> 4. Run a shell script using the value in the edit control as a parameter >> and return the results in text area 2 >> >> I have OpenDBX running successfully and I don't think using OSProcess and >> CommandShell will be that difficult. >> >> Creating the form is the part I don't know how to accomplish. >> >> I have done some searching and there seems to be a surprising dearth of >> info on how to create a simple GUI from scratch using Pharo or Squeak. >> >> -- >> Frank Church >> >> ======================= >> http://devblog.brahmancreations.com >> > > -- Frank Church ======================= http://devblog.brahmancreations.com

Jan. 8, 2013

Re: [Pharo-project] Spec news

by StÃ©phane Ducasse

Ok so to clarify what I want with Spec: - move LayoutFrame outside of Morphic. Now I'm not sure that spec should depend on it, may be. - LayoutFrame is a bad name for a transformation specification. - I do not think that an Array is good but I do not think that using two rectangles is good either Do we think that (0@0 corner: 1@1). (0@22 corner: 0@0). is readable? No it looks quite bad and as bad as #(0 0 1 1 0 22 0 0) Probably we should have layout {LayoutFrame rightOffset: 22) instead of specifying everything when this is not needed especially since now LayoutFrame new is equivalent to (0@0 corner: 1@1). (0@00 corner: 0@0) - Finally we should not edit by hand such methods and esteban will work on that. - We should - rethink the contents of spec methods they should cover structural information such color, defaultExtent; minimalExtent:â¦and this should be modular (it is already). Each kind of spec should be responsible of declaring what it needs to create its visual component. - we should be able to mix structural specification with DSL driven ones. RIght now when you use the dsl you cannot specify structural information at the composite level (I may be wrong) - rethink if we use a class for each specific spec elements so that we can build nice visitors I do not remember how this is done in Spec. In VW this is like that (but visitors are not used or I missed them). - revisit the interpreter because it is not modular. right now this is difficult to extend it and it would be better that the interpreter delegates to each of the spec elements their interpretation. Have a look at the method interpretASpec: aPresenter - rethink the asArray methods. You will see that they implement some spec layout algorithms that are not independent of Morphic and quite complex (note that we simplified these methods). So we should understand and see because I have the impression that they are outside of Spec more on layout in general. - with igor we fixed fractions:offsets because it creates rectangles with negative height and width. => this brings some problems when we want to fix intersect: and this is really important because the intersection of disjoint rectangles is not a negative ones. Right now this works because the primitives are discarding call with negative arguments but this is doomed by construction. Now we could have ignored Spec and let benjamin do the dirty work and we would have waited to be able to go to the next step. So we took our energy and fixed Spec too which I think is normal because if this is part of the infrastructure then we should maintain it. But we are not expert on Spec and it would have been more fun to do it with Ben. Now we just did what we think is good and during holidays is one of the few moment of calm I can haveâ¦. so we did it at that time because of that. Stef > On 8 January 2013 18:12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Benjamin Van Ryseghem-2 wrote >>> Why using a meaningless array when we could use object ? >> >> +1. This seems hard to use/understand. If we don't want to depend on >> Morphic, let Spec define its own intention revealing messages. > > Or pull LayoutFrame out into a separate package. That Morphic depends > on that new package doesn't matter at all; what matters is that > LayoutFrame doesn't depend on Morphic. LayoutFrame's a nice simple > class. > > frank >

Jan. 8, 2013