- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

It also means that we should find somebody that do not piss on metacello and maintain a version for Seaside. Because we cannot manage complex system with a package management system and there is a cost in that but benefit too. Sad but true. Stef On May 31, 2011, at 9:55 PM, Sean P. DeNigris 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? 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] Metacello as the system evolves... (Fwd from Seaside-General: Which image for deployment?)

by StÃ©phane Ducasse

sean can you quote the name of the person who wrote the mail? Stef On May 31, 2011, at 9:55 PM, Sean P. DeNigris 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? 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] [squeak-dev] Fwd: usability of Pharo and Squeak

by Janko MivÅ¡ek

On 31. 05. 2011 18:35, Ramon Leon wrote: > Tabs would make it more like practically every other program available > that needs multiple edit windows. Tabs are better than multiple > windows. Look around, tabs won; the battle is over. Tabbed browsing of > the net or 15 instances of Firefox open? Seriously, you think multiple > windows are better? Really? Agreed, tabs won, therefore we need to implement it and this will be a big step forward for usability of our tools. Not only for newcomers, for us too. You will see sooner or later that tabbed windows are better than full ones. I had such experience from VW and other VisualWorkers would probably confirm that. Ok, a right combo of both, tabbed and full. Say two browsers windows with a reasonable amount of methods open in tabs. And adding back button .. well that would be near nirvana considering current state :) Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

May 31, 2011

Re: [Pharo-project] [Pharo-users] [PBE-Spanish] Status udpate 2011-05-31

by StÃ©phane Ducasse

Thanks thanks thanks nicolas!!! Keep pushing. Stef > Hello everyone, > > I am coordinating the group working on the Spanish translation of Pharo By Example. Our goal is to have a first rough draft of the whole book by end of June. > > I am glad to announce that the draft of the first 3 translated chapter is now available. You can find under the new section it in http://pharobyexample.org/ or with this direct link: https://gforge.inria.fr/frs/download.php/28586/PBE1-Spanish-Draft-2011-05-2… > > The current status of the translation is: > > Chapter 01: 20% > > Chapter 02: 60% > > Chapter 03: 100%, already publish > > Chapter 04: 100%, already publish > > Chapter 05: 50% > > Chapter 06: 7% > > Chapter 07: 46% > > Chapter 08: 0% > > Chapter 09: 100%, not published yet > > Chapter 11: 100%, already published > > Chapter 12: 19% > > Chapter 13: 0% > > Chapter 14: 100%, not published yet > > > > From now onwards I will send regular status updates. > If somebody is interested in collaborating (translating or reviewing), just let me know. > > Regards, > > NicoPaez. > blog: nicopaez.wordpress.com

May 31, 2011

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

by Igor Stasenko

On 31 May 2011 23:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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? > Yes, you could swallow all ErrorNonInteractive. So if you will know that something will lead to UI interaction, you can catch ErrorNonInteractive. Since there is no UI you won't proceed further, but still will know that during running the test some UI is involved. So, actually a following should pass: UIManager default isInteractive ifFalse: [ self should: [1 inspect] raise: ErrorNonInteractive ] The problem is that there is some missing protocol in NonInteractiveUIManager (because at the time i was adding it , i covered all methods, but then some more stuff were added to morphic ui manager without parallel extension to other ui managers, so the test above can fail because you will get DNU error instead of ErrorNonInteractive ). > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

May 31, 2011

Re: [Pharo-project] loading code from command line inovcation

by StÃ©phane Ducasse

>> > > Another detail is, that users on the commandline expect errors to go to stderr and not to some 'hidden' log file. > > Would it be possible to have that recognized on startup and have errors redirected to stderr instead of a log file? if you send code you increase the chances to get what can help you. > > Thanks > Stefan

May 31, 2011

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