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

Re: [Pharo-project] Learnable Programming

by Goubier Thierry

Cool! There are some very nice program flow representations in them. I'll have a look if I can display Jejak traces that way, and maybe explore the use of Roassal for this. Thierry Le 26/09/2012 21:59, Sven Van Caekenberghe a Ã©crit : > This is _very_ interesting and _very_ welll presented: > > http://worrydream.com/LearnableProgramming/ > > Keep on reading, it keeps on getting better towards the end. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 27, 2012

Re: [Pharo-project] vm download site

by Camillo Bruni

On 2012-09-26, at 22:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 September 2012 20:42, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> http://pharo.gforge.inria.fr/ci/vm/mac >> http://pharo.gforge.inria.fr/ci/vm/linux >> >> and once we fixed the win builds >> http://pharo.gforge.inria.fr/ci/vm/mac/win >> > this url doesn't looks right. Perhaps you meant > > http://pharo.gforge.inria.fr/ci/vm/win yes of course :) the mac/win platform is yet to be invented :P

Sept. 27, 2012

Re: [Pharo-project] Workspace>>#theme

by Camillo Bruni

The workspace has been taken out of the StringHolder hierarchy with a bit too little love ;) https://code.google.com/p/pharo/issues/detail?id=6717 On 2012-09-26, at 22:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Clicking the window menu of a Workspace in 20308 gives a MNU Workspace>>#theme in Workspace>>#addModelItemsToWindowMenu: > > Maybe Workspace subclassing from Object is the problem ? > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Sept. 27, 2012

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

by Yanni Chiu

On 26/09/12 11:07 AM, Yanni Chiu wrote: > > I'll try a bit more to get it to work on 10.5.8, now that I can build a VM. Okay, got it to work! Three changes: 1. SqueakOSXAppDelegate.h - use NSObject instead ofNSApplicationDelegate 2. sqSqueakOSXScreenAndWindow.h - use NSObject instead of NSWindowDelegate 3. SqueakOSXAppDelegate.m - use CoreGraphics instead of OpenGL //#ifndef USE_CORE_GRAPHICS //# import "sqSqueakOSXOpenGLView.h" //# define ContentViewClass sqSqueakOSXOpenGLView //#else # import "sqSqueakOSXCGView.h" # define ContentViewClass sqSqueakOSXCGView //#endif ==== Along the way, I found: Issue 5650: OneClick 1.4 can't be launched on MacOSX Mac Air 10.5.8 http://code.google.com/p/pharo/issues/detail?id=5650 While I agree that support for old OS releases should have a reasonable limit, I don't buy 10.5 dropped when 10.8 is around the corner is the right limit. My machine is circa 2009, just three years or so. Apple may have good reason to want to move the user/developer base off of 10.5, because of hardware (pad/phone) and UI native widget changes. In the Squeak/Pharo case, we just need a single window to draw in - that should hardly obsolete a three year old computer. I'll add this thread to the issue report (5650).

Sept. 26, 2012

Re: [Pharo-project] Roassal Survey

by Francois Stephany

On 26/09/12 15:19, Alexandre Bergel wrote: >>> Our todo list includes: >>> - book chapter on Roassal >> >> Maybe don't bother with that. Write short blog posts showing the stuff you can currently do with Roassal. And keep writing as the project evolves. >> >> I feel like the time a book is out, it's already outdated by the implementation. > > :-) > Well... My students are asking for a piece of documentation. And in my opinion, book chapter are more read than blog :-) You're right, a book has probably more authority than a blog post. And its probably more perenial as well. But a blog post is more aligned with *my* way of consuming tech/programming/library/framework information :p

Sept. 26, 2012

Re: [Pharo-project] Roassal Survey

by Alexandre Bergel

>> Our todo list includes: >> - book chapter on Roassal > > Maybe don't bother with that. Write short blog posts showing the stuff you can currently do with Roassal. And keep writing as the project evolves. > > I feel like the time a book is out, it's already outdated by the implementation. :-) Well... My students are asking for a piece of documentation. And in my opinion, book chapter are more read than blog :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 26, 2012

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

by HernÃ¡n Morales Durand

Hi Levente, On 26/09/2012 2:25, Levente Uzonyi 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. > Yes, for compatiblity I'm currently using Grease as much as I can. Read my reply to Benoit about the ANSI Smalltalk. > 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 > > This was what I wanted. Thanks for the tips, Levente. Cheers, HernÃ¡n > 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] Transform sends to ANSI standard?

by HernÃ¡n Morales Durand

On 25/09/2012 19:35, Benoit St-Jean wrote: > 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. Hi Benoit, Just for the record :) I've worked with a custom implementation of Smalltalk which was 100% tested ANSI-compatible. It was in 2004 and unfortunately the project never saw the light except for our customer. However I wasn't in the team responsible for the ANSI compliance, but for the testing. It was called "Chachara Smalltalk" and it has some interesting features at that time: No object table, compacting generational GC with variable # of generations, C++ VM with reified ST meta-model, etc. You may see a screenshot in the attachment, that proves nothing, but sometimes it's nice to see screenshots. > > 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. > Yes, but the goal of the standard is to provide an ideal protocol of behaviors. Globals are only defined if they conform a protocol. UI, Database and Graphics were unspecified until Smalltalk implementations converge... which could be never. > Unfortunately, we're not in the Java world. You'll eventually need a > Bundle/Application/Project/Package named "Portability" just like > everyone else... > I'm afraid so... I wonder what's the status of Grease. Any Seasider reading? Cheers, HernÃ¡n

Sept. 26, 2012

Re: [Pharo-project] Roassal Survey

by Francois Stephany

> Our todo list includes: > - book chapter on Roassal Maybe don't bother with that. Write short blog posts showing the stuff you can currently do with Roassal. And keep writing as the project evolves. I feel like the time a book is out, it's already outdated by the implementation.

Sept. 26, 2012

Re: [Pharo-project] vm download site

by Igor Stasenko

On 26 September 2012 20:42, Camillo Bruni <camillobruni(a)gmail.com> wrote: > http://pharo.gforge.inria.fr/ci/vm/mac > http://pharo.gforge.inria.fr/ci/vm/linux > > and once we fixed the win builds > http://pharo.gforge.inria.fr/ci/vm/mac/win > this url doesn't looks right. Perhaps you meant http://pharo.gforge.inria.fr/ci/vm/win > best > igor + cami > -- Best regards, Igor Stasenko.

Sept. 26, 2012