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

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

by Yanni Chiu

On 26/09/12 6:03 AM, Igor Stasenko wrote: >> - 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. >> > is there a reason why you cannot upgrade your OS? No reason other than it used to happen automatically when I got a new machine. That hasn't happened yet. I'll try a bit more to get it to work on 10.5.8, now that I can build a VM.

Sept. 26, 2012

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

by Yanni Chiu

On 26/09/12 3:17 AM, Stephan Eggermont wrote: > http://stackoverflow.com/questions/1496788/building-for-10-5-in-xcode-3-2-o… I found that last night too. I ended up replacing: NSApplicationDelegate --> NSObject NSWindowDelegate --> NSObject in the two declarations. With the change, I successfully built a VM. But, the VM behaved in exactly the same way - displaying only a blank window. BTW, I noticed there was already code that was commented out, which effectively did the same as the above. My understanding now is that NSApplicationDelegate and NSWindowDelegate just provide compile time checks on the implemented protocol, meant to formalize a previously informal protocol. So, the underlying implementation is somehow dependent on OSX-10.6 behaviour.

Sept. 26, 2012

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

by Dale Henrichs

Cami, Work on Phd? Do you have a bug number for that? Thanks for the effort, man! I'll just wait a bit longer before integration:) Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, September 26, 2012 2:10:36 AM | Subject: Re: [Pharo-project] OSProcess ... ported to 2.0? | | | 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

[Pharo-project] latest images mirror

by Camillo Bruni

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

Sept. 26, 2012

[Pharo-project] Roassal Survey

by Torsten Bergmann

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.

Sept. 26, 2012

[Pharo-project] [update 2.0] #20308

by Marcus Denker

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

Sept. 26, 2012

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