- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Roassal Survey

by Ben Coman

You asked for it.... Three scenarios... 1. Mind Mapping tool similar to http://freemind.sourceforge.net <http://freemind.sourceforge.net/> - MEDIUM priority. I think Roassal would provide a lot of advantages to such an application - and in return be a great reference case for testing interactions - and great possibilities of running Smalltalk scripts against the graph - and draw new users unwittingly to learn Smalltalk. 2. Project Management Tool similar to Microsoft Project - LOW priority. The two main players in the project management space are Primevera and Microsoft Project. Most of the features of these are overkill for most small projects and actually never used by users. Many people use VERY basic features of Microsoft Project to just manually build nice looking dependency graphs. This part Roassal could do very well. Over time other contributors with more project management domain knowledge might build in more sophisticated features. A Smalltalk backed project management scripting tool would be really great. And again, new users drawn just to the application may be unwittingly introduced to Smalltalk (and of course, once introduced are hooked for life). 3. Electrical Software Development Platform - CRITICAL priority Of course, my own project to complete my masters within the next couple of months!! This is implementing a model browser for the IEC 61970 Common Information Model. I showed this to Alex a while ago and am just now getting back to the point I was at before switching from Mondrian to Roassal. While this has taken a while I am very happy with the additional control I have with Roassal (and a lot of this time has been too many demands by my day job). Perhaps a rough early release is not too far away. And four features... (some of these may just be not knowing how to apply existing features) ... 4. Static layouts saved to file - CRITICAL priority. I need to be able to arrange the elements in a Roassal graph, then save that to disk and later load this up in another image. I suspect that doing this using Fuel would be very cool. 5. Static Magritte-Roassal links - CRITICAL priority. Currently in my use of the Magritte-Roassal combination, if in Magritte I select an element and then drag elements to arrange then in the "downstream" Roassal graph, when I select another Magritte item, my arrangement is lost as the layout is reapplied to the whole graph. What I would like is for Roassal to highlight the item selected in Magritte without reapplying layout to the graph. A layout would only be applied to a graph when manually applied - much like the ROMondrianExample>>chooseLayout. 6. Swapping between static layouts - HIGH priority As well, for a single model I need be able to have several views in one window pane, where in one I put nodes into one arrangement, change to another view where I put nodes into another arrangement and flip back and forth between the two arrangements. 7. Constrain elements so they can't overlap - MEDIUM priority. Currently nodes are initially laid out so that they don't overlap, however there is no constraint on them from being moved so that they later overlap. It would be good if elements could be constrained from so that they could not overlap. Similar to how moving a child element past the border of the parent dynamically resizes the parent, trying to move a first element over the top of a second element would either: (a.) push the second element in the direction the first element it is being dragged; or (b.) the first element would get stuck at the edge of the second element. In both cases, the subsequent behavior could be: (c.) the first and second elements continue to interact in the same regardless of how far the mouse moves; or (d.) once the mouse has moved past the bounds of the second element, the first and second element swap positions. 8 Interactively creating graphs - MEDIUM priority Creating a graph by adding elements from within the Roassal graph and adding edges by dragging links between two elements. Just before I started switching my application from Mondrian to Roassal, I added this functionality to Mondrian and soon I need to re-implement this in Roassal. Having done it once in Mondrian I reckon I've a good chance of doing the same for Roassal, where as I can't do (4.) & (5.) myself. hope this helps, cheers -ben Alexandre Bergel wrote: > 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. >>> >>> >>> >> > >

Sept. 26, 2012

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

by H. Hirzel

On 9/26/12, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 25 Sep 2012, 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? > > Is there an ANSI compatible Smalltalk implementation out there? I doubt > it. If I were you, then I'd use a compatibility layer like Sport or > Grease, instead of relying on the ANSI standard. > > But to answer your question: you should check how these methods are > implemented and check if the implementation is ANSI compatible or not. In > most cases they are: > > string cr ==> Character cr asString > > #lf same as above > > stream cr ==> stream nextPut: Character cr > > #lf, #space, #tab similar to #cr > > stream crlf ==> stream nextPut: Character cr; nextPut: Character lf > > #findTokens: ==> no ANSI compatible method. If the argument is a single > character, then you can create a stream on the collection and use #upTo: > to find the parts. > > collection collect: aBlock thenDo: anotherBlock ==> (collection collect: > aBlock) do: anotherBlock > > collection detectSum: aBlock ==> collection inject: 0 into: [ :sum :each | > sum + (aBlock value: each) ] > > #valuesDo: ==> use #do: or #keysAndValuesDo: instead > > #keysSortedSafely ==> sorting is not part of the ANSI standard, only > SortedCollection is, so you can use something like: collection keys > asSortedCollection: [ :a :b | <copy the contents of the sort block here from > #keysSortedSafely> ] > > Array new: x withAll: y ==> (Array new: x) atAllPut: y > > > Levente > > P.S.: My problem with the ANSI standard is that it seems more like > something that documents the common things in Smalltalks at the time of > its creation instead of a complete and future-proof base API. +1, in the 90ties. The ANSI standard is not maintained. http://www.smalltalk.org/versions/ANSIStandardSmalltalk.html --Hannes > >> >> Best regards, >> >> HernÃ¡n >> >> >>

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 13:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > 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. > This is highly platform-specific. The ioProcessEvents called by VM during interrupt , so, platform-specific code can use it to signal any pending external events. Interrupts is also used by scheduler to switch to another process when something happens (like socket has new data to read, semaphore signaled etc). So, if VM won't support interrupts it will be highly problematic to support green threading execution model. And, of course, an interrupt is naturally a well-defined safe point in VM execution. So it is logical to have an entry point there, where plugin(s) can hook-in and add own custom event handling procedure, without need for patching a single global ioProcessEvents() function over and over again. If at some point you'll have two independent modules (plugins) in VM which want to put own custom handling code there, you can always do it like following pseudocode: (during plugin initialization) oldHandler := ioProcessEvents. ioProcessEvents := &myHandler. (during call ) myHandler self doMyHandling. call oldHandler Now, of course it is a question, how often you may need that: a module which adds own custom handler for VM interrupt. Maybe we don't need that much flexibility? But do others see other way of freeing VM from assumptions and tight coupling with different parts of system? -- Best regards, Igor Stasenko.

Sept. 26, 2012

Re: [Pharo-project] Roassal Survey

by Alexandre Bergel

> I have a colleague who is working on epidemiological modeling and he > needs to be able to visualize epidemiological data from Vietnam from a > lot of diseases in order to discover some patterns. He already done > some work by hand and definitively need some way to automate the > process. Sound interesting! Let's talk about this during your visit in Chile Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 26, 2012

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

by Fernando Olivero

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. >

Sept. 26, 2012

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

by Igor Stasenko

On 26 September 2012 05:13, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/09/12 11:33 AM, Yanni Chiu wrote: >> >> >> So any ideas? > > > I tried to build the CogVM. > - search for build instructions, blog post, etc. > - almost give up in frustration before discovering the process noted below > :) > - download the tar ball from: > > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/ > - find and install cmake > - already had a C compiler installed > - the HOWTOBUILD file said: > cd build > cmake . > make > - the build path is hard coded so: yes, this is an unavoidable outcome of being able to specify custom paths by developer for sources/build directories.. they are written into directories.cmake file. Initially all paths there was relative, but since user can specify own (absolute) custom paths, there is no way how it can keep working using relative paths. You can edit this file, or you can just run an image placed in ./image subdirectory and rerun cmake files generation on you machine, so paths will be fixed automagically. > % mkdir -p Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/ > % mv ~/src > Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog > # where ~/src is the un-tar'ed tar ball from above > - run cmake and make again (sometimes had to remove CMakeCache.txt file) > - build fails at: > ==== > [ 77%] Building CXX object > CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o > In file included from > /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m:44: > /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/OSX/SqueakOSXAppDelegate.h:46: > error: cannot find protocol declaration for âNSApplicationDelegateâ > make[2]: *** > [CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o] > Error 1 > make[1]: *** [CMakeFiles/CogVM.dir/all] Error 2 > make: *** [all] Error 2 > ==== > - the culprit is the line: > @interface SqueakOSXAppDelegate : sqSqueakAppDelegate > <NSApplicationDelegate> > - web search for NSApplicationDelegate > - find Apple dev page that says: > NSApplicationDelegate - Available in OS X v10.6 and later. > > So, is there an important reason to use NSApplicationDelegate? IIUC, it > results in the VM requiring OSX 10.6 or higher, which means my 10.5.8 will > never work with CogVM's built this way. > is there a reason why you cannot upgrade your OS? -- Best regards, Igor Stasenko.

Sept. 26, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 375 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 26, 2012

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

by Camillo Bruni

On 2012-09-25, at 18:59, Dale Henrichs <dhenrich(a)vmware.com> wrote: > 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 ok, that's what I feared :/ since I did only a quick tryout and didn't properly separate the classes from the rest of the FileSystem I opened an issue on the tracker, currently I have to take a break from fixing stuff and work on my phd :P... https://code.google.com/p/pharo/issues/detail?id=6740 cami

Sept. 26, 2012

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

by Stephan Eggermont

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

Sept. 26, 2012

Re: [Pharo-project] Roassal Survey

by Serge Stinckwich

On Tue, Sep 25, 2012 at 10:15 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > 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. Thank you Alex & Vanessa for all your great work on Roassal ! > 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. I'm really interested to push Roassal in this direction. I have a colleague who is working on epidemiological modeling and he needs to be able to visualize epidemiological data from Vietnam from a lot of diseases in order to discover some patterns. He already done some work by hand and definitively need some way to automate the process. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Sept. 26, 2012