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

Re: [Pharo-dev] Can't correctly inspect ring definitions

by Martin Dias

On Wed, Sep 18, 2013 at 7:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Sep 18, 2013, at 5:28 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> RGClassDescriptionDefinition should be polymorphic with >> ClassDescription. But #instVarNamed: is protocol of Object, so why to >> override it there? >> >> Concretely, I have instances of RGClassDefinition and I can't: >> >> 1) inspect them as regular objects >> 2) use STON to serialize >> >> Because both use #instVarNamed:, which is answering nil. > > but why does it answer nil and not the object? you can try by inspecting this, for example: Integer asRingDefinition if you click in the inspector on 'annotations', which is an instvar of RGClassDefinition, what you see is nil. This is because #instVarNamed: tries to find 'annotations' in Integer (not in the RGClassDefinition).

Sept. 19, 2013

Re: [Pharo-dev] if Pharo is key for you

by Sven Van Caekenberghe

On 19 Sep 2013, at 01:07, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > OFF TOPIC. IGNORE AT WILL. > > 2013/9/18 Sven Van Caekenberghe <sven(a)stfx.eu>: >> On 18 Sep 2013, at 21:41, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > >>> (*) Sorry it is blurred, I can't disclose more than this. >> >> This is seriously cool, really. >> Too bad you can't say more ;-) >> I for one am very interested ! > > Well... that's an screenshot for a demo we did (no persistence, no > authentication, no nothing, just the basic logic). I understand. But what does it do, basically ? Show the positions of mobile devices on a map ? Are there two parts to the (web) app, a part on mobile devices and a part on a desktop ? What else does it do ? -- but I would understand if you prefer not to discuss it (yet) > Footnote: We built and demoed everything ALIVE so fast that they > thought we already completed the development of the solution, others > were still gathering requirements or doing Powerpoints... that's a key > advantage of a self contained solution like Pharo. Then you must have a good team with very good developers as well ;-) > It hasn't changed much on the frontend (it should) but I've been > working hard in the middleware and the android client (Java is a pain > in the a** to debug, but the "user perceived value" is 100x of > anything else you could do). > STAMP will come handy if this gets real and with the planned user base > of 200-1000 clients. > I'm a big fan of all your frameworks. Thx. > Meanwhile we just keep our fingers crossed... to have the pilot (50 > users) approved... big companies are slowâ¦ Good luck. > Esteban A. Maringolo Sven

Sept. 19, 2013

Re: [Pharo-dev] Can't correctly inspect ring definitions

by Marcus Denker

On Sep 18, 2013, at 5:29 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > RGClassDescriptionDefinition should be polymorphic with > ClassDescription. But #instVarNamed: is protocol of Object, so why to > override it there? > > Concretely, I have instances of RGClassDefinition and I can't: > > 1) inspect them as regular objects > 2) use STON to serialize > > Because both use #instVarNamed:, which is answering nil. > To me it looks wrong for RGClassDefinition implementing #instVarNamed:. Marcus

Sept. 19, 2013

Re: [Pharo-dev] [OT] Pharo lighthouse wallpaper

by Sven Van Caekenberghe

On 19 Sep 2013, at 01:57, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > I'm using this Windows theme since the beginning of the year. With > sounds and everything :) > http://windows.microsoft.com/is-is/windows/lighthouses-download-theme > Esteban A. Maringolo Beautiful, too bad the pictures are copyrighted, they fit Pharo perfectly ! > 2013/9/18 Torsten Bergmann <astares(a)gmx.de>: >> http://wallpapers5.com/images/wallpapers/71156968/Photography/Cape-Hatteras… >> >> According to site Image is for personal, non commercial use >> >

Sept. 19, 2013

"OS" and "OS-Windows" project on STHub

by Torsten Bergmann

Damien wrote: >Do you already have continuous integration set up or do you want me to do it? No, not yet. I've a CI account but was not able to create projects with it. Would be nice if you could help setting it up. Obvious that it requires a windows slave. The code already takes care that the tests run only on Windows (there is a class WindowsSpecificTest as a subclass of TestCase overriding #isAbstract). Bye T.

Sept. 19, 2013

Re: [Pharo-dev] [ANN] "OS" and "OS-Windows" project on STHub

by Damien Cassou

that's really great news, thank you very much for your work. Do you already have continuous integration set up or do you want me to do it? On Wed, Sep 18, 2013 at 11:49 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > with NativeBoost (NB) it is now possible to access not only external libraries but also the > underlying operating system platform. Some examples are already included in the > "NativeBoost-Win32", "NativeBoost-Unix" and "NativeBoost-Mac" categories within the NB project. > > But providing more and more examples and native API wrappers for the various platforms > directly within the NativeBoost project itself would only bloat this project. NB should care > about being a good external interface - nothing more. > > To keep NativeBoost clean with the basic functionality for a good foreign function > interface Igor suggested to move specific API wrappers for the various operating systems into > own project. To avoid duplicate effort in providing such wrappers it would IMHO make sense to > host them in a central place. > > Therefore I created the "OS" Team on SmalltalkHub with a first project called > "OS-Windows" allowing you to access Win32/Win64 functionality easily from within > Pharo. It contains code, tests, many examples and documentation as a first contribution. > > With this initial project for Windows you can now work with the console, Shell, the internet > explorer, GDI, windows processes, Control panel applets, ... > > I refer to the written documentation and many examples given at: > > http://smalltalkhub.com/#!/~OS/OS-Windows > > Provided code for Windows is stable and usable, if you have something to share to make > it even more complete then you can easily contribute (how is described in the docu). > > Code is for Pharo 3.0 - you can load it easily from the config browser in a recent image. > Try the examples given in the docu on the project page, look at the tests to get comfortable > with it. > > Important: > ========== > Note that this idea is NOT LIMITED TO WINDOWS - it would be good if we could see pair > projects like a "/~OS/OS-Mac", or "/~OS/OS-Linux" and others under the same umbrella > so it follows a common pattern and is easier to access for people who require it. > > If someone asks if Pharo is platform independent I will answer: YES. If he asks if > it is also playing nicely with the underlying platform to use platform dependent functionality > I would also like to answer YES. > > If he wants to do some Mac stuff I would like to tell him: "just load "OS-Mac" from the > config browser and start. Same for Linux, Windows, Android, YouNameIt, ... > > I can only provide a start for the basic framework with the hope that others will > contribute as well and getting it into good shape as yet another good step for the > possibilities in the Pharo universe. > > Side note: > ========== > You can read the docu online at the SmalltalkHub project page (http://smalltalkhub.com/#!/~OS/OS-Windows) > - but also as a class comment on the ConfigurationOfOSWindows. If you have the "Pharo Online Help" > loaded you can also view it there. > > Keep on talking small > T. > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 19, 2013

Re: [Pharo-dev] Smalltalkhub => 503

by btc＠openinworld.com

Sept. 19, 2013

[SOLVED]ConfigurationOfGlorpDBX for Pharo2.0

by Federico.Balaguer

It actually worked, the image was unresponsive for a couple minutes but after that everything (so far) seems to be working. Thanks again! Federico -- View this message in context: http://forum.world.st/ConfigurationOfGlorpDBX-for-Pharo2-0-tp4709086p470909… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 19, 2013

Do not use shouldnt:raise:

by Camillo Bruni

Warning, long post. I accidentally run the dev version of moose on a 2.0 to check if the VMs work properly and I ran into a bunch of failing tests. https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM-AcceptanceTest/27/SLAVE=p… First of all, my problem, since I wanted to test the #stable release anyway. In any case I had a look at the bugs since I was interested to see if it was in any way VM-related: https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM-AcceptanceTest/27/SLAVE=p… Ok, 0 information :(, why? Because of #shouldnt:raise:. On a linguistic basis the #shouldnt:raise: message makes sense, sort of the counter part of #should:raise:... BUT how does it handle errors exactly? Example 1: ---------- self shouldnt: [ 1 doeSomething ] raise: MessageNotUnderstood. ok, seems fine, the test should fail, most probably with an assertion failure, and this is what it does indeed. Example 2: ---------- self shouldnt: [ 1/0 ] raise: MessageNotUnderstood. will that now fail or not? Because it doesn't raise the MessageNotUnderstood, so the logic conclusion is that it doesn't fail. Well, you're wrong, it WILL FAIL, with a ZeroDivide, which is the major reason #shouldnt:raise: is not helpful. That is utterly confusing and rather useless. Because you can just write 1 doeSomething. 1/0. - In case 1 you get an MessageNotUnderstood instead of an AssertionFailure => test fails in both cases - In the second case you get the same message, so nothing to discuss about. The interesting part is, that case 1 almost never happens like I've shown it. Most of the time it looks more like this (including the failing moose tests): self shouldnt: [ 1 doeSomething ] raise: Error. This is in my eye useless, even worse, it is obstructing, since you basically mute an otherwise useful error. In the original example, I was left with no stack trace nor a decent reason why the test would fail. Whereas with a bit of stack trace I would get reasonable context to start real debugging efforts. Conclusion: ----------- a) do not use #shouldnt:raise: b) still don't use it c) if you want to use #shouldnt:raise: for dubious reasons, use very specific errors you test for, othew

Sept. 19, 2013

Re: [Pharo-dev] ConfigurationOfGlorpDBX for Pharo2.0

by Federico.Balaguer

Hola Rochi it does not load the configuration. The image freezes up... saludos! federico -- View this message in context: http://forum.world.st/ConfigurationOfGlorpDBX-for-Pharo2-0-tp4709086p470909… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 19, 2013