- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] FileSystem inconsistency

by StÃ©phane Ducasse

+1 >> 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?

Jan. 8, 2013

Re: [Pharo-project] Spec news

by Frank Shearar

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

Re: [Pharo-project] NativeBoost design and deployment

by Eliot Miranda

On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: > > When one deploys an image one usually requires ONLY > > the image - not the source or changes file. An "image locker" > > code would look like this: > > > > SmalltalkImage checkSourcesFileAvailability: false. > > SmalltalkImage checkChangesFileAvailability: false > > > > do disable acording warnings when source/changefile is removed. > > > > If one uses NativeBoost in such a deployment scenario, for > > instance the > > > > NBWin32Shell shellBrowse: 'http://www.google.de' > > > > functionality the internal code (due to missing source) now > > looks like this > > > > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 > > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR > #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' > > > > Hence the t1 ... t5 parameters. > > > > NativeBoost is in this situation not able to match the > > FFI parameters and throws an error "Could not find accessor for variable > ..." > > > > Try yourself without a changes and source file. This makes > > NativeBoost not very deployment friendly and unusable in > > such a "minimal deployment" scenario ... > > > > Any comments? > > > > yes it needs sources (indirectly) to bind method's argument names > during code generation. > To avoid that, i can imagine that one must modify a compiler to detect > if compiled method > primitive requires arg names, and store them in method properties. > Like that later code generator can use them without need to access the > source code. > Indeed. If a pragma were used then the whole thing could look a lot nicer, not be dependent on source, and include support for an error code. e.g. shellExecute: lpOperation file: lpFile parameters: lpParameters directory: lpDirectory show: nShowCmd <nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' errorCode: ec> ^self nbCallFailedWith: ec It's pretty trivial to add such pragma compilers to the compiler. There is an example for the FFI. It also frees one to use a nicer syntax, e.g. shellExecute: lpOperation file: lpFile parameters: lpParameters directory: lpDirectory show: nShowCmd <nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)' module: 'Shell32.dll' errorCode: ec> ^self nbCallFailedWith: ec > > Thanks > > T. > > > > -- > Best regards, > Igor Stasenko > > -- best, Eliot

Jan. 8, 2013

Re: [Pharo-project] FileSystem inconsistency

by Camillo Bruni

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?

Jan. 8, 2013