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

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

by Igor Stasenko

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.

Sept. 26, 2012

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

by Igor Stasenko

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.

Sept. 26, 2012

Re: [Pharo-project] No GUI on MacOSX 10.5.8 using Cocoa VM

by Yanni Chiu

On 25/09/12 5:49 PM, Igor Stasenko wrote: > I don't understand, is this happen only if you "copy" plugin from one > VM to another? I use the VM's as built. A long time ago I tried to "copy" plugins from one place to another, but I could never get it to work (on MacOSX) - so, in my mind that has never been an approach to try anymore. I'll try copying the Inria-built SSL plugin to the Eliot-built VM, and see what happens.

Sept. 25, 2012

Re: [Pharo-project] Transform sends to ANSI standard?

by Benoit St-Jean

On 25/09/2012 2:31 PM, HernÃ¡n Morales Durand wrote: > > Hi folks, > I am rewriting packages to be compatible or more portable between > Smalltalks. Code Critics gives the following information on my packages: > > - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the > ANSI string protocol. > > - #cr and #lf are not part of the ANSI stream protocol. > > - The ANSI standard does not support #asInteger and #asString on Object. > > - Some collection methods are not ANSI compatible: #pairsDo:, > #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:, > #keysSortedSafely, #new:withAll:, etc. > > Does anyone have an idea on how to transform those sends to be ANSI > compatible? Hi Hernan, I don't think being ANSI-compatible should be a goal in any case. You won't find any Smalltalk flavor (commercial or Open Source) that is fully ANSI-compatible. All vendors have their extensions/exceptions/versions. Just have a look at Glorp to convince yourself of differences between Smalltalk implementations! But if your goal is portability, I'd say you should start by having your code compatible with VAST, VW, Dolphin & Squeak. You'll probably cover most of other Smalltalks variants by doing so. The ANSI standard was never, to my knowledge, 100% fully respected by any Smalltalk vendor. Most of them tried to but none of them implemented it with 100% compliance. In other words, just do your best at satisfying compatibility with the most vendors. This one uses Xtreams, the other one Nautilus browser or Zinc, the other one starts Array indices at 1, this other one does this, the other one does that, one uses Smalltalk while the other uses SmalltalkImage, etc. Unfortunately, we're not in the Java world. You'll eventually need a Bundle/Application/Project/Package named "Portability" just like everyone else...

Sept. 25, 2012

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

by Igor Stasenko

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. > 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? 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. -- Best regards, Igor Stasenko.

Sept. 25, 2012

Re: [Pharo-project] No GUI on MacOSX 10.5.8 using Cocoa VM

by Igor Stasenko

On 25 September 2012 17:33, Yanni Chiu <yanni(a)rogers.com> wrote: > I use Pharo-1.4 using the VM's from > http://www.mirandabanda.org/files/Cog/VM/ > > Now I want to use Zodiac, so I need the SSL plugin. The SSL plugin is > pre-built in the VM's from > > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/ > > But, when I run with this CogVM, I get only a blank window (on MacOSX > 10.5.8). When I compared the two executables using "otool -L" it looks like, > from the shared library list, that Eliot's VM is Carbon based, and the > "Pharo" VM is Cocoa based. > I'm not sure what happen. Could be that two VMs have some incompatibility. Usually copying plugins should work. Except that yes, Carbon/Coocan mix and match.. this can have some side effects. > Even though I could only see a blank window, the CPU usage seemed to be > normal (3-5%), so I decided to try accessing the Seaside app that was > already running in the image, and found that it was working fine. Since I > had RFB/VNC loaded, I could enable it, and connect to the image via a VNC > viewer. > > It seems that the image is running in "headless" mode. I tried older Pharo > images, as well as newer/older Pharo CogVM's, and got the same blank window. > > I added some code the the VNCController app to get the remote UI to work. > The code was: > self uiProcess isNil > ifTrue: [ UIManager default: MorphicUIManager new ] > > Even though there's now a MorphicUIManager set, the window is still blank. > > So any ideas? > > Does the VM fall back to headless mode when it cannot init the graphics on > my older MacOS? > > Does the MorphicUIManager need to be set in the startup code, else it's too > late? > I don't understand, is this happen only if you "copy" plugin from one VM to another? > -- > Yanni > > -- Best regards, Igor Stasenko.

Sept. 25, 2012

Re: [Pharo-project] Roassal Survey

by Alexandre Bergel

This is not that we do not have ideas :-) Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability We obtained this list from our personal needs and the need of the Moose and VW communities. Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity. And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support. Cheers, Alexandre On Sep 25, 2012, at 12:33 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > I don't know your project scope, but these pointers may help you to grab some features to implement: > > http://www.tm4.org/mev/features > > Also take a look into the Circular Genome Viewer: http://wishart.biology.ualberta.ca/cgview/gallery.html > > specially the browsable maps > > http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/inde… > > check out the Expand+ and Rotate+ operations > > Other very nice engine is Circos > > http://circos.ca/ > > which contains plots that has been published in Science, Nature and PLOS. > > Cheers, > > HernÃ¡n > > > On 25/09/2012 11:48, Vanessa PeÃ±a Araya wrote: >> Hello! >> As you probably know, Roassal was presented at ESUG. We received a lot >> of positive feedback from you and also a lot of request for features. >> Thank you very much! >> >> We want to start working on this, but also prioritize what seems to be >> more urgent. >> For this, we would like to survey the community about >> 1 - what are the features you would like to see in Roassal. Please, >> provide a list of features requests and tell us about their priority >> 2 - scenarios where you would like to use Roassal. >> >> Thank you very much, >> Vanessa. >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 25, 2012

[Pharo-project] Transform sends to ANSI standard?

by HernÃ¡n Morales Durand

Hi folks, I am rewriting packages to be compatible or more portable between Smalltalks. Code Critics gives the following information on my packages: - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the ANSI string protocol. - #cr and #lf are not part of the ANSI stream protocol. - The ANSI standard does not support #asInteger and #asString on Object. - Some collection methods are not ANSI compatible: #pairsDo:, #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:, #keysSortedSafely, #new:withAll:, etc. Does anyone have an idea on how to transform those sends to be ANSI compatible? Best regards, HernÃ¡n

Sept. 25, 2012

Re: [Pharo-project] The roadmap aka fight plan to make image control host window

by Eliot Miranda

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. This code has been used for years in the Newspeak system which has a full native GUI on Windows. Going your own way creates an unnecessary fork. > 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. > > -- best, Eliot

Sept. 25, 2012

Re: [Pharo-project] OSProcess ... ported to 2.0?

by Dale Henrichs

Cami, Your code seems to have conflicts with the implementation of FileSystem in Pharo-2.0 ... besides overriding a number of methods (most that I looked at involved comments) there are a couple of places where the class names have been changed ... so it looks like your wrapper code has become outdated ... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, September 24, 2012 11:23:35 PM | Subject: Re: [Pharo-project] OSProcess ... ported to 2.0? | | | On 2012-09-25, at 01:11, Dale Henrichs <dhenrich(a)vmware.com> wrote: | | > As I take yet another stab at getting the Metacello Preview running | > on Pharo2.0, I find that OSProcess is sprinkled with references to | > FileDirectory ... at least in the packages referenced by the | > configuration, so I'm wondering if a port exists for Phar0-2.0 ... | > At the moment OSProcess is a prerequisite .... | | use my compatibility layer for FileDirectory, which wraps around | FileReference: | http://smalltalkhub.com/mc/dh83/fisleg/main | | With that it should be possible to load most old code in 2.0. | There are a 4 methods or so I haven't ported yet and I should | properly isolate the package... | | > If there is an alternate mechanism for running shell commands from | > Pharo2.0, then I assume that I'll be able to use that instead ... | | currently there isn't any other option :/ |

Sept. 25, 2012