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

Re: [Pharo-project] Numerical packages

by Nicolas Cellier

I can tell you about Smallapack as author. First advantage: using a state of the art robust library LAPACK + BLAS is the core of Matlab/Octave/Scilab/R/etc... It is robust in terms of API stability, numerical stability, and number of bugs (try finding known ones). Second advantage: combine advantages of - a fast and efficient number crunching library for low level primitives - and our favourite IDE for higher level code (interpreter debugger browser etc...) That's the exact strategy developped by Matlab. As a bonus, Smalltalk interpreter is faster than Matlab, and don't ask me about Matlab language design (non) choices ;) To reach Matlab core preformances, you need an optimized version of BLAS (ATLAS for example). I imagine versions of these libraries could exploit multi-core parallelism (but I did not check status of http://www.netlib.org/scalapack/) Good news, I have a working Smallapack in both Dolphin and VW. Unfortunately, the main drawback is that Squeak/Pharo is not in that list. First, Smallapack may crash the image in Squeak/Pharo... I've not found the reasons, but suspect some FFI problems. Maybe I should try using a plugin rather than FFI. That seems doable since low level FFI code is generated automatically from Lapack comments. It's just a matter of changing code generator to generate slang rather than FFI... Second drawback is that loading Smallapack in a Squeak/Pharo image requires some pre-requisite. This is because LAPACK has the bad property of having functions with more than 16 arguments. Squeak/Pharo Compiler cannot handle methods with that many arguments. I have a Compiler hack ready for handling this case. I have not automated the process because I'm not so sure that Gofer/Metacello are good for installing such hack (Compiler overrides may seem evil). But I can help any good will. So, if you're after an off-the-shelf library working out of the box, Smallapack is not OK. However, if above goals fit yours, and you're willing to help, I'll be happy to revive the project and inject a few hours into it. Nicolas 2011/5/31 Ignacio Vivona <altobarba(a)gmail.com>: > Hi all! I'm currently planning on doing some work related to resolving > partial differential equations (shallow water) in pharo. I'm seeing a couple > of project for dealing with vectors, matrices and some other math things. > http://www.squeaksource.com/DHBNumerical.html > http://www.squeaksource.com/MatrixPlugin.html > http://www.squeaksource.com/Numerics.html > http://www.squeaksource.com/Smallapack.html > Has anyone any experience working with these? > Also I'm looking at Mathmorphs (does it work in > pharo?)Â http://mate.dm.uba.ar/~caniglia/mathMorphs.htmlÂ and > DrGEOÂ http://community.ofset.org/index.php/DrGeoÂ for doing the graphical > interaction. > If someone knows of some other project related please guide me. > Thanks in advance, > Ignacio Vivona

May 31, 2011

Re: [Pharo-project] testing ui errors in headless mode

by Tudor Girba

Hi Igor, Sorry for the late reply. On 26 May 2011, at 17:48, Igor Stasenko wrote: > On 26 May 2011 17:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I tried several ways to get my head around this problem, but I do not know how to proceed. Can anyone help? >> >> Cheers, >> Doru >> >> >> On 25 May 2011, at 21:21, Tudor Girba wrote: >> >>> Hi, >>> >>> We have some smoke tests in Moose that basically spawn a UI and check for Error. >>> >>> This used to work when running headless in Pharo 1.2 but now they fail in Pharo 1.3. I believe this has to do with the new changes in the UI Manager, but I do not know what to do. >>> >>> To reproduce the problem, you can simply call a Pharo-1.3.image in headless mode and file in the attached st file that: >>> >>> - installs a simple test: >>> HeadlessTest>>testStartup >>> self shouldnt: [1 inspect] raise: Error > > Tudor, your test is wrong. > During image startup and in headless mode calling inspector will and > should raise an error. > Because inspecting object requires a presence of UI. > But there's no UI in headless mode and prohibited from use during > image startup phase, because > you cannot start asking questions from user before properly > initializing everything related to startup. > Startup is called startup on purpose: is should not be interrupted nor > require user's interaction. > > Assume that you don't have Morphic loaded in your image, then what you > expect to happen if you do > 1 inspect > ? I understand now that the test is wrong. I just wanted to offer an example of spawning a ui, but I think I found the problem like this :). Now, the thing is that my test tests that triggering the entries from a menu does not result in an error. And inspect or browse happen to be among the menu entries. Is there a way to still have this test working on the server? Should I put a guard condition in the method triggering the inspector? That sounds bad. Any other ideas? Cheers, Doru >>> >>> - loads HudsonTools >>> >>> - runs the test and outputs the XML file report >>> >>> - although the test should pass, it raises the error: >>> HeadlessStartupTest(TestCase)>>signalFailure: >>> HeadlessStartupTest(TestCase)>>assert: >>> HeadlessStartupTest(TestCase)>>shouldnt:raise: >>> HeadlessStartupTest>>testStartup >>> HeadlessStartupTest(TestCase)>>performTest >>> >>> >>> Can anyone help? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "What is more important: To be happy, or to make happy?" >>> >>> <headlesstest.st> >> >> -- >> www.tudorgirba.com >> >> "It's not what we do that matters most, it's how we do it." >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "It's not how it is, it is how we see it."

May 31, 2011

Re: [Pharo-project] Metacello as the system evolves... (Fwd from Seaside-General: Which image for deployment?)

by Mariano Martinez Peck

On Tue, May 31, 2011 at 9:55 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > The following is a conversation about not being able to load Seaside into > Pharo 1.2 via Metacello (from the Seaside-general list). Shouldn't symbolic > versions in Metacello have solved this problem? No. #symbolic versions DOES solve the problem in the general way. But it is up to the ConfigurationOf maitainer to assure that. If ConfigurationOfSeaside doesn't load is not because of Metacello. Is because nobody fix ConfigurationOfSeaside and #stable to make it work. Cheers mariano > There should be different > package versions tagged stable for each system (1.2.x, 1.3...) as > necessary, > no? It seems there's not much difference between: > Pharo 1.2 vs. Pharo 1.3 > and > Pharo 1.2 vs. Squeak 4.2 > > Doesn't symbolic versions finally allow us to have *one* configuration per > project that will load into any Squeak/Pharo/etc? As a Metacello user, it > would be comforting to know that there is only one configuration, or > needing > to find the /right/ one replaces one problem (dependencies) with another. > > > > >> * loading Seaside via Metacello into Pharo (although I got an error in > >> Pharo > >> 1.2.2-12353) > > > > That is a known problem (see > > > http://lists.squeakfoundation.org/pipermail/seaside-dev/2011-May/004786.html > > and http://www.iam.unibe.ch/pipermail/moose-dev/2011-May/008309.html) > > Some configurations that the Seaside Metacello Configuration depens on > > have been updated to Pharo 1.3 breaking all users of older versions of > > Pharo. > > > > I was told that the (Pharo?) Metacello configurations do not support > > loading into older images. So people that want to use a stable version > > of Pharo (< 1.3) cannot load Seaside with Metacello anymore. There are > > various solutions: > > > > - Move to (unstable) Pharo 1.3, use a maybe broken Seaside, and load > > the code easily with Metacello (this is what Pharo wants us to do) > > - Fix the configurations of Pharo or write our own configurations (no > > clue how that could be done) > > - Stay with (stable) Pharo and use Gofer scripts (this is what I do, > > works pretty reliable and painless) > > > > In either case you should complain in the Pharo list, there is > > something broken in the process. Personally, I am fedup with these > > forced updates and will stick with Pharo 1.2 until there is a really > > compelling reason to move forward. > > > > -- > View this message in context: > http://forum.world.st/Metacello-as-the-system-evolves-Fwd-from-Seaside-Gene… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 31, 2011

[Pharo-project] Metacello as the system evolves... (Fwd from Seaside-General: Which image for deployment?)

by Sean P. DeNigris

The following is a conversation about not being able to load Seaside into Pharo 1.2 via Metacello (from the Seaside-general list). Shouldn't symbolic versions in Metacello have solved this problem? There should be different package versions tagged stable for each system (1.2.x, 1.3...) as necessary, no? It seems there's not much difference between: Pharo 1.2 vs. Pharo 1.3 and Pharo 1.2 vs. Squeak 4.2 Doesn't symbolic versions finally allow us to have *one* configuration per project that will load into any Squeak/Pharo/etc? As a Metacello user, it would be comforting to know that there is only one configuration, or needing to find the /right/ one replaces one problem (dependencies) with another. >> * loading Seaside via Metacello into Pharo (although I got an error in >> Pharo >> 1.2.2-12353) > > That is a known problem (see > http://lists.squeakfoundation.org/pipermail/seaside-dev/2011-May/004786.html > and http://www.iam.unibe.ch/pipermail/moose-dev/2011-May/008309.html) > Some configurations that the Seaside Metacello Configuration depens on > have been updated to Pharo 1.3 breaking all users of older versions of > Pharo. > > I was told that the (Pharo?) Metacello configurations do not support > loading into older images. So people that want to use a stable version > of Pharo (< 1.3) cannot load Seaside with Metacello anymore. There are > various solutions: > > - Move to (unstable) Pharo 1.3, use a maybe broken Seaside, and load > the code easily with Metacello (this is what Pharo wants us to do) > - Fix the configurations of Pharo or write our own configurations (no > clue how that could be done) > - Stay with (stable) Pharo and use Gofer scripts (this is what I do, > works pretty reliable and painless) > > In either case you should complain in the Pharo list, there is > something broken in the process. Personally, I am fedup with these > forced updates and will stick with Pharo 1.2 until there is a really > compelling reason to move forward. > -- View this message in context: http://forum.world.st/Metacello-as-the-system-evolves-Fwd-from-Seaside-Gene… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 31, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Igor Stasenko

On 31 May 2011 21:44, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Another idea (don't know how hard it is) is to have test coverage + comment > coverage in Hudson. > Then we can start to consider that dead code = code with no test or no > comment. Laurent, have you tried to run lint rule checker in pharo image? I tried once and if i remember correctly, there are like 30000 notices. Now, what you think, is it possible for any human to visit all of them step by step analyze and then fix the code? It is enormous amount of data (and most of it is just white noise, or insignificant detail). Now how to filter that noise and address the only things which you should take care of? And since we're continuting development, every time you doing an update, this stuff should be revisited, compared and cross-checked again. And we don't have such facility: take image A and B, and compare their lint output. I imagine this would require a quite sophisticated database , with UI on top of that, which will allow you to navigate through these notices mark them as invalid, or fixed etc etc.. What i mean that automated tools is cool. But they cannot solve all our problems: every such issue should be analyzed and considered by developer. Because we're still not yet at the point, where system can reason about itself and automatically improve itself without need of our attention :) If this day will come, then it will be the end of humanity (at least in its current form - homo sapiens sapiens ;) > Laurent. > -- Best regards, Igor Stasenko AKA sig.

May 31, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 69 - HostSystemMenusWindows

by Guillermo Polito

Me and the HostSystemMenusMacOSX are specializations of HostSystemMenusProxy. We know how to answer to #isActiveHostMenuProxyClass, which is used by HostSystemMenus class>>activeMenuProxyClass to determine the active menu. That's why I don't have direct references. Read HostSystemMenusProxy for more info. On Tue, May 31, 2011 at 3:51 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: HostSystemMenusWindows > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

May 31, 2011

[Pharo-project] [COTDC] 69 - HostSystemMenusWindows

by laurent laffont

Today: HostSystemMenusWindows Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

May 31, 2011

Re: [Pharo-project] TilingWM improvements

by laurent laffont

> > > I write a test, to do the following (but you can load this method and you > can do now at hand to understand what I mean): maximize a window, use > topWindowMoveTop, then topWindowMoveBottonLeft. The result is that the > window is 1 / 8 the size of the screen (I attach screenshot). With the > resolution size of the current monitors or the possibility of having > multiple monitors and extend the main window Pharo through these, using > windows of 1 / 4 of the screen can be a waste, plus there are tools that do > not need more a small space. > Moreover, this way you can only have 4 move operations: topWindowMoveTop / > Bottom / Left / Rigth, since the rest of you combined the above. > Ah OK. Estelle at our local coding-dojo today told me that in xmonad there's this sort of behavior. Maybe another way is to add #moveUpward / #moveDownward / #moveLeftward / #moveRightward mapped to keyboard shortcuts. Laurent. > > > >> I've implemented automatic refresh (see TilingWMSettings >> class>>initialize). May break the first time you load it if you have a >> version before the change. >> > > Yes, I see, thanks. > > >> >> There's a first shot of GUI controls for world snapshot / navigation but >> it needs more work to be intuitive. >> >> > There are many new features, it is time to make a new screencast:) > > > > >> Laurent. >> >> 2011/5/28 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >> >>> Laurent, coincidere change this method (o part of): >>> >>> TilingWM>>newTopWindowBoundsInArea: aBlock >>> SystemWindow topWindow bounds: (aBlock value: world clearArea). >>> >>> to this one: >>> >>> TilingWM>>newTopWindowBoundsInArea: aBlock >>> | topWindow | >>> (topWindow := SystemWindow topWindow) isMaximized >>> ifTrue: [ topWindow expandBoxHit. topWindow bounds: (aBlock value: world >>> clearArea) ] >>> ifFalse: [ topWindow bounds: (aBlock value: topWindow bounds) ] >>> >>> >>> For one hand this solve the problem of maximized state on moved window, >>> and for other hand apply recursive "moving" of window based in their current >>> bounds (but not usable display area) if that is not in state maximize (I >>> choose this rule for my convenience). >>> >>> --- >>> >>> When I load new version of this package, I use the Settings to see new >>> version de la barra, but the old version keep visible too, and I use >>> SHIFT-ALT-Click to see the halos and remove this. Is possible clean up of >>> older versions of bar automatically? >>> >>> ---- >>> >>> And I see that you comming work in TWMWindowSnapshot :) I like it, I hate >>> wasting time accommodating the size and position of the windows manually >>> because I want to have another hearing, again and again! >>> >>> >>> >> >

May 31, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by laurent laffont

Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment. Laurent. On Sat, May 28, 2011 at 3:35 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > There is *a lot* of dead code in the image. > > I guess around 1/3 of the code base in Core is just not used at all > (especially Morphic). > > One thing I would like to do is to put, at the beginning of a development > cycle, > a call > > self doesAnyOneUseThisTaggedIn: 'pharo 1.3'. > > at the beginning of *all* unsent methods. And keep it even in the released > image. > > This way we can, within 2-3 interations, remove *a lot* of dead code. > > Methods where people tell us that they need them, we should tag > with <api> or <public> or something like that. > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

May 31, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 68 - MultiNewParagraph

by laurent laffont

Thanks a lot Alain !!! Laurent. On Sun, May 29, 2011 at 3:33 AM, Alain Plantec <alain.plantec(a)yahoo.com>wrote: > Class intention > My intention is the same as my super class. This is a good reason to > merge me with my super class and to remove me. > My main supplementary intention is to display the different kinds of > text selection (secondary, find-replace and selection bar). > > Class collaborations > SelectionBlock instances are built by myself and stored in the > extraSelectionBlocks instance variable in order to display supplementary > selections > > Class main API > no particular main API. > > > Instance Variables > extraSelectionBlocks: <Collection of SelectionBlock> > findReplaceSelectionRegex: <RxMatcher> > presentationLines: <Object> > presentationText: <Object> > refreshExtraSelection: <Boolean> > secondarySelection: <String> > > extraSelectionBlocks > - a collection of SelectionBlock for the drowing of the differents kind > of text selection > > findReplaceSelectionRegex > - the find/replace matcher that is set from the editor of by the > FindReplaceService > > presentationLines > - created for debugging purpose, should be removed ? > > presentationText > - created for debugging purpose, should be removed ? > > refreshExtraSelection > - a boolean that is set to tru when there is a need to refresh > selections > > secondarySelection > - the string of the secondary selection that is set from the editor when > a portion of text is selected > > > > Le 25/05/2011 22:50, laurent laffont a Ã©crit : > >> On Tue, May 24, 2011 at 11:15 PM, Igor Stasenko <siguctua(a)gmail.com<mailto: >> siguctua(a)gmail.com>> wrote: >> >> On 24 May 2011 22:31, laurent laffont <laurent.laffont(a)gmail.com >> <mailto:laurent.laffont@gmail.com>> wrote: >> > Today: MultiNewParagraph >> >> Alain Plantec could say more, since more of the methods in this class >> marked under his authorship. >> >> >> >> Alain, do you have 5mn :) ? >> >> Laurent. >> >> >> > Comment Of The Day Contest - One Day One Comment >> > Rules: >> > #1: Each day a not commented class is elected. Each day the best >> comment >> > will be integrated with name of the author(s). >> > #2: If you cannot comment it, deprecate it. >> > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> > Laurent >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >> >

May 31, 2011