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

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

by Levente Uzonyi

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. > > Best regards, > > HernÃ¡n > > >

Sept. 26, 2012

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

by Yanni Chiu

[re-sending since gmane may have swallowed it] 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. [Update - I looked at the directory structure of the Cocoa vs Carbon apps, and decided to try to build the VM instead of trying to splice in a plugin. It doesn't seem to be just a simple .so file to be copied.]

Sept. 26, 2012

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

by Yanni Chiu

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

Sept. 26, 2012

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

by Igor Stasenko

.. and you can always create own extension methods #cr -> #carriageReturn etc but as Benoit said, even if you do it, this won't make your code automagically portable across all smalltalk dialects. You will still need portability package per each dialect, otherwise you'll have to implement own streams, collections etc. -- Best regards, Igor Stasenko.

Sept. 26, 2012