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

[Pharo-project] Roassal Survey
by Torsten Bergmann Sept. 26, 2012

Sept. 26, 2012

I just wonder what is necessary to use Roassal not only as a visualization engine of existing data but to give it more interactivity to create new data/shapes/connections. An example: one can build a UML class shape and visualize the existing class hierarchy of Pharo with the current engine. But is it possible to also hook into the engine so one can have a palette and by visually adding new nodes (here UML classes) and wire them visually to create new classes in the system and use it as a modeling tool too? Simply said: whats required to additionally transform it into a universal diagram tool with palette for custom shapes and connections, outline, custom menues on shapes/nodes/connections to open dialogs, properties page ... Something similar to GEF from Eclipse http://www.eclipse.org/gef/ http://www.eclipse.org/articles/Article-GEF-diagram-editor/shape.html I'm sure this would open up lots of opportunities to build graphical applications with Pharo. Thx T.

2 1

Re: [Pharo-project] No GUI on MacOSX 10.5.8 using Cocoa VM
by Stephan Eggermont Sept. 26, 2012

Sept. 26, 2012

http://stackoverflow.com/questions/1496788/building-for-10-5-in-xcode-3-2-o…

2 1

[Pharo-project] latest images mirror
by Camillo Bruni Sept. 26, 2012

Sept. 26, 2012

We have an additional place to download images from: http://pharo.gforge.inria.fr/ci/image/ you will find the latest builds under the following link http://pharo.gforge.inria.fr/ci/image/latest.zip other images can be downloaded by their full version number http://pharo.gforge.inria.fr/ci/image/20307.zip currently older versions from 2.0 are uploaded. best cami

1 0

[Pharo-project] [update 2.0] #20308
by Marcus Denker Sept. 26, 2012

Sept. 26, 2012

20308 ----- Issue 6739: Remove URI client classes concept http://code.google.com/p/pharo/issues/detail?id=6739 Issue 6725: Character Conversion Cleanup http://code.google.com/p/pharo/issues/detail?id=6725 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window
by Fernando Olivero Sept. 26, 2012

Sept. 26, 2012

Igor, i agree 100% percent with you! VM shouldn't have all the responsibility of handling a "single UI window". I've tried in the past to look at VM code, which handles this responsibility and change it, (no UI handling in the VM) ..but it proved to be a difficult task! We need a simpler, cleaner VM, pluggable UI handling would be awesome!. Do we need the pointer or Null at all in the VM? Cant the io handling be done completely separate from the VM? A native app for each platform, or something built using NB. Fernando On Wed, Sep 26, 2012 at 2:57 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Remember, Andreas added a nice new feature into (at least) windows > VMs, where upon startup it showing a splash image? > By reading a .bmp file and delaying rest of process by couple seconds. > That maybe useful. But what if tomorrow, my customer will want to keep > showing it, till user click on it? > What you will do? Right! Go and hack VM. And what if he will want to > show splash and progress bar while loading/initializing stuff? Another > shitloads of code into VM? > And something fantastic, what if customer would like to use different > image format for splash screen, png, jpeg? And what if we would like > to automatically download the splash image from web site before > showing it? > > So, where is the end of this? When you will finally say "enough", we > need proper window management in image? > > > -- > Best regards, > Igor Stasenko. >

2 1

[Pharo-project] pharo-2.0-tests Â» win - Build # 334 - Failure!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr Sept. 26, 2012

Sept. 26, 2012

1 28

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window
by Igor Stasenko Sept. 26, 2012

Sept. 26, 2012

On 26 September 2012 00:47, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Sep 25, 2012 at 3:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> On 25 September 2012 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > On Sat, Sep 22, 2012 at 11:22 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> First, we need to make one thing: >> >> >> >> Change the VM to not call ioProcessEvents function directly, but >> >> rather use a variable which will hold a function pointer. >> >> Initially, when VM starts, that function pointer is NULL, and so, >> >> "process events" is NOP. >> > >> > >> > Please don't reinvent the wheel. The Cog source has a variable inIOProcessEvents that controls this. If negative it disables inIOProcessEvents. If non-negative it prevents reentrancy, essential if one is receiving events from the OS. There's a primitive, primitiveEventProcessingControl, to flip it between the enabled and disabled states. >> > >> Yes i seen that. >> But apparently, i don't want to just disable it by putting NULL, but >> also i want to replace it (or wrap it) with own io handler (see >> NativeBoost ;). For that, i need the function pointer. > > > Unlikely. Better to call the relevant function through the FFI. If you're implementing a native gui you don't need the VM involved in deciding when to poll for events. > The idea about function pointer was to move ioProcessEvents into separate plugin. Like that, if you don't build VM with this plugin, you automatically have no UI and no ioProcessEvents, because there's nobody who registers that function. And then platform VM code is no longer obliged to implement that function. For me it is first logical step in decoupling GUI handling from the core VM feature set. While having the flag simply disabling that function from being called. >> > This code has been used for years in the Newspeak system which has a full native GUI on Windows. >> > > > >> >> Does that means that implementation is completely on language side? If >> so, then why you need the rotten window management code in VM? > > > One doesn't need it. It's there and lies unused. > So why you need to keep something which is unused? Especially when it is flawed, limiting and plainly wrong? >> >> Lately, i seen Mars running native GUI (browser window) using Cocoa on >> macs and GTK on linux. >> (but you still have VM window hanging around, and you cannot get rid of it). >> >> > Going your own way creates an unnecessary fork. >> > >> I would love to not reinvent it, but the user input handling is one of >> the weakest spots in current VM implementaion. >> I don't like many things there: >> - VM is in control whether to create window or not >> - VM in control what attributes window has >> - VM in control how to translate OS (native) events to >> "squeak-compatible" events, often losing important bits and making >> everything crawl like hell >> - VM in control when to update/refresh a window >> - VM decides whether it run headless or not >> - VM decides when to handle input events >> list can be continued.. >> >> Personally, i don't like that image assuming that VM has to provide a >> single "default" window >> for it. It is image, which should manage that (if it wants to), but not VM. > > > You don't. But you don't need two VMs either. The existing VM windowing code can coexist with the native GUI code. In fact one can use the old code to debug the new code, and if you're Vassili you can switch an open window from Squeak window to native window and back :) And, what will prevent you from using new API for GUI handling, provided by VM plugin do to the same what Vassili did? And is there a point in future, where you can say "okay, let's throw this out, because it rotten to death and obsolete and there's far better alternative(s)?" Or there's no such point exists? You must know well, that at certain point, if you need to reach higher quality levels in doing something, you must rethink, what tools you will be using (or create new, finer tools). One cannot do DNA engineering using magnifying glass, one needs microscope. Unless we want to prevent people from even considering using smalltalk for something more serious than weekend hobby experiments. Because keeping low-quality infrastructure will make sure it will stay like that. Well, maybe you right, maybe this stuff is not worth touching, but instead it is better to think how to completely circumvent it and let it rot there. But personally, i won't feel happy knowing that VM contains code which nobody uses and sits there waiting for someone who will attempt to run 20-years old images. For me it doesn't makes sense: if you want to run 20-years old image, use 20-years old VM. Compatibility problem solved. -- Best regards, Igor Stasenko.

1 1

[Pharo-project] The roadmap aka fight plan to make image control host window
by Igor Stasenko Sept. 25, 2012

Sept. 25, 2012

First, we need to make one thing: Change the VM to not call ioProcessEvents function directly, but rather use a variable which will hold a function pointer. Initially, when VM starts, that function pointer is NULL, and so, "process events" is NOP. Then we need to implement a module which will manage host windows, and once image tells it to create a window, it can change the function pointer to ioProcessEvents to own function. This change, would allow us to temporary disable any external event processing (like in case of callbacks). Second, we should move all event-related stuff to new plugin (for instance, all definitions in sq.h like sqInputEvent , ioSetInputSemaphore() ioGetNextEvent() etc). For all UI-related stuff the image should communicate with a new plugin, while VM should get rid of all knowledge of any existence of UI events, like input semaphores, primitives for fetching them etc. Third, of course, all screen update/refresh primitives should be deprecated, and image should use new primitives to update the contents of host window(s). -- Best regards, Igor Stasenko.

3 3

[Pharo-project] [update 2.0] #20307
by Marcus Denker Sept. 25, 2012

Sept. 25, 2012

20307 ----- Issue 6724: String additions + cleanup http://code.google.com/p/pharo/issues/detail?id=6724 Issue 6531: Not possible to save one click image on Windows http://code.google.com/p/pharo/issues/detail?id=6531 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] instVarNames vs instVarNamed:
by Fernando Olivero Sept. 25, 2012

Sept. 25, 2012

...makes me envy the simplicity of SELF! Fernando On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 September 2012 08:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote: >> >>> okay, i found what is wrong with first post (didn't read carefully). >>> >>> The instVarNames is a class-side protocol i.e. part of a class behavior, >>> while instVarNamed: is an instance-side protocol i.e. "hackishly >>> access to instance variable with given name" >> >> Yes this is exactly my point. >> I think that there is a protocol missing for class to be consistent. >> > err, what is missing? class is an object, and using #instVarNamed: on > them is perfectly fine. > > >>> So, this is ok: >>> Nautilus class instVarNames >>> -> #('maxSize' 'cachedLastClasses' 'groups') >>> >>> And this is ok too: >>> >>> Nautilus instVarNamed: 'groups' >>> worked >>> >>> because Nautilus is an instance of its metaclass. >>> >>> But this is wrong, since 'Nautilus class' is an instance of Metaclass, >>> and metaclass doesn't have 'groups' variable. >>> >>> Nautilus class instVarNamed: 'groups' >>> -> error >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

7 16