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

Re: [Pharo-project] Have you played with Ameba?
by Marcus Denker April 25, 2012

April 25, 2012

On Jun 10, 2011, at 3:54 PM, Alexandre Bergel wrote: > Fun :-) > > Indeed! I want a yellow one made of circles... because it reminds me of a german kids tv show that I liked *a lot* when I was little: http://www.youtube.com/watch?v=OSlJYoRrh0k :-) > On 9 Jun 2011, at 09:56, HwaJong Oh wrote: > >> "Load package" >> Gofer new >> squeaksource: 'DaliotsPlayground'; >> package: 'Ameba'; >> load. >> >> "run objects" >> x := Ameba example. >> >> "kill objects" >> x do: #delete. >> >> -- >> View this message in context: http://forum.world.st/Have-you-played-with-Ameba-tp3585624p3585624.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 6

[Pharo-project] Fwd: OSProcess - is process done?
by DeNigris Sean April 25, 2012

April 25, 2012

Begin forwarded message: > From: "David T. Lewis" <lewis(a)mail.msen.com> > Subject: Re: [Pharo-project] OSProcess - is process done? > Date: April 24, 2012 8:59:03 PM EDT > To: Pharo-project(a)lists.gforge.inria.fr, sean(a)clipperadams.com > > On Fri, Apr 20, 2012 at 03:02:38PM -0700, Sean P. DeNigris wrote: >> Here's the OSProcess test results: >> >> * Pharo 1.3 >> * Mac Lion 10.7.3 >> * recent Cog VM from the Pharo CI server >> * latest version of OSProcess (the all-in-one package, not the broken up >> ones) >> >> 192 run, 110 passes, 0 expected failures, 79 failures, 3 errors, 0 >> unexpected passes >> Is that what you would expect?! >> > > Hi Sean, > > I do not have a Mac, so I cannot really reproduce what you are doing. > But for what it's worth, I did some testing on my Linux machine with > Pharo 1.4. > > OSProcess and CommandShell will run on Pharo 1.4 although there are a > few problems to be sorted out. The attached screen shot shows results > of a full test run using a 64-bit interpreter VM on Linux with the three > required plugins (OSProcessPlugin, AioPlugin, and XDisplayControlPlugin). > > I made some updates to both OSProcess and CommandShell to address issues > flushed out by Pharo 1.4. These are minor updates, but you may want to update > to the latest versions from SqueakSource. > > Cog VM distributions do not include AioPlugin or XDisplayControlPlugin, > and a portion of the OSProcess/CommandShell test suite will fail because > of this. The AioPlugin should work with Cog but is not distributed. > XDisplayControlPlugin does not yet work with Cog and it probably will > never work on OS X. Most OSProcess functionality will work without these > plugins, so the main impact is just on the test suite. > > Pharo 1.4 deprecates #withBlanksTrimmed and #withoutTrailingBlanks, and > suggests replacing them with Pharo methods that do not exist in other images. > I do not know what to do about this for OSProcess/CommandShell, so I just > commented out the deprecations in order to run the tests (turning off the > deprecation warning preferences does not work, see below). > > Something seems to be broken in the interaction of deprecation warnings > and the test runner. If I do not comment out the deprecations in the actual > methods, the test runner will show tests as failing (presumably because an > exception was thrown), but they pass when I try to debug them (so maybe the > exception is being handled normally when debugging, and is ignored?). > As noted above, I just commented out the deprecations in the methods to > make the problem go away. > > HTH, > Dave >

1 0

[Pharo-project] CogVM on linux machines
by Herve Verjus April 25, 2012

April 25, 2012

Hello All, I am currently try to deploy the 1.4 Pharo CogVm on different linux machines. The underlying aim is to propose a stable linux configuration that will be deployed in our university (for Smalltalk/Pharo lectures and students practice). As far as for now, we have windows workstations on which Pharo (1.3) was installed: during this year, we meet some troubles (Pharo images containing students' work no more readable or crashing all the time :-( ). Students complain... I really want to seperate VM install (on the workstations) with the image files (on separate students' home directories) that's why the oneClick bundle does not interest me. I made some tests on different linux machines and I find some problems: - on a 5 years old machine with a fresh installed latest Ubuntu (v11), the CogVm crashes (segmentation fault)...while the 1.4 oneClick installation is running well. The same install on another but same model machine with the same linux distribution (same version), the CogVm immediately ends with this error Syntax error: "(" unexpected - on a more recent machine with a up-to-date Ubuntu LTS (v10), the CogVm works well Any advices are welcome and if some of you have linux requirements/specifications don't hesitate to tell me ;-) Regards, Herve -- -- Herve VERJUS -----ooOoo----- http://univ.herveverjus.com/ -- Universite de Savoie - IAE Savoie Mont-Blanc -- Directeur du Departement Technologie et Management / IMUS-IAE -- Resp. Master Management et Technologies de l'Information -- B.P. 80439 / F-74944 ANNECY-LE-VIEUX -- Reception: +33 (0)450092443 - Office 009: +33 (0)450092415 -- LISTIC Lab. - Polytech Annecy-Chambery Office A225

3 6

[Pharo-project] Athens & SVG (was: Re: new icon set )
by Igor Stasenko April 25, 2012

April 25, 2012

Hi, there i uploaded an alpha version of Athens-SVG package on squeaksource/Athens. Many things are working, and many not yet ;) I testing things by trying to render different svg files using it like that: [1] (ASVGMorph fromFile: 'lion.svg') drawOn: Display getCanvas or like that: [2] (ASVGMorph fromFile: '7-icon-set/Connect$70426968946611.svg') setZoom: 10; drawOn: Display getCanvas (of course you can just use #openInWorld instead of #drawOn:) (and of course you don't have to create a morph.. you can just import svg getting an instance of ASVGRoot class, and then render it on any Athens canvas. [1] http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg [2] http://www.tehkseven.net/blog/1/entry-1066-475-free-awesome-high-quality-ic… -- Best regards, Igor Stasenko.

4 5

[Pharo-project] ballon-help in 1.4
by Hilaire Fernandes April 25, 2012

April 25, 2012

Is it only me or do you also experience Ballon-help text looking ugly again. After some time using the image it got in ugly formating mode. Hilaire -- Dr. Geo -- http://www.drgeo.eu

2 6

[Pharo-project] SimpleLiteralArray Spec
by Sven Van Caekenberghe April 25, 2012

April 25, 2012

OK, just to get started, let try to write a spec for SimpleLiteralArray, this is based on JSON (and my own STON, not ready for public consumption). It will soon become clear that this is slightly harder than expected, IMO a writer is needed as well. S y n t a x value primitive-value list nil primitive-value number true false symbol string classname list #() #( elements ) elements value value , elements string '' ' chars ' chars char char chars char any-printable-ASCII-character- except-"-or-\ \" \\ \/ \b \f \n \r \t \u four-hex-digits symbol # chars-limited # ' chars ' chars-limited char-limited char-limited chars-limited char-limited a-z A-Z 0-9 - _ . / classname uppercase-alpha-char alphanumeric-char number int int frac int exp int frac exp int digit digit1-9 digits - digit - digit1-9 digits frac . digits exp e digits digits digit digit digits e e e+ e- E E+ E- Questions remain: - is the escaping OK ? - what about symbols without a leading # ? - what should be allowed in unquoted symbols ? - what should be allowed for classnames ? - what about namespaces ? - do we allow infinite precision integers ? - maybe the toplevel should always be an array ? Now: shoot! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

11 32

[Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]
by Igor Stasenko April 25, 2012

April 25, 2012

Hi, Dale it is great to see an effort in such direction. I just wonder what .js files doing there? According to what i see, it is just a meta data which holding additional properties per entity.. { "category" : "Cypress-Tests", "classinstvars" : [ ], "classtraitcomposition" : "{}", "classvars" : [ ], "commentStamp" : "", "instvars" : [ ], "name" : "CypressPatchTest", "pools" : [ ], "super" : "CypressAbstractTest", "traitcomposition" : "{}", "type" : "normal" } why you cannot use a regular smalltalk literal syntax for this data? What/why there is need to store this data in json format? On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Bernhard, > > With regards to sharing code between dialects, I'd like to recommend that you look into porting Cypress to Cuis (I'm willing to help as much as I can). > > The Cypress project is aimed from the get go to enable sharing of packages between Smalltalk dialects with a recognition that possibly the most important aspect is a shared VCS (git/github). > > If you look at the current code base in Cypress, you will see a reference implementation written against Pharo. The reference implementation is a work in progress and the initial implementation was done for Amber[2]. > > Cypress has Monticello-like packages, but other than taking a few ideas from Monticello (definitions, packages and snapshots ... more than a few:)) the code base is independent of Monticello. The fact that Cypress runs on top of Amber (sans file system access) speaks volumes for it's portability. > > To paraphrase a point from my STIC talk[3] on this subject: > > Â Cypress is not intended to be the primary version control > Â system for any dialect, however, if you want to share code > Â between dialects you should allow your developers to import > Â and export code using the Cypress package format. > > If you are interested, there are bits and pieces of code in a few other projects that I would want to pull into the Cypress project and couple other things that I'd like to move out of the Cypress project before tackling another port ... > > We can correspond via private email if you'd like to take me up on the offer of help:) > > Dale > > [1] https://github.com/CampSmalltalk/Cypress > [2] https://github.com/CampSmalltalk/amber-cypress > [3] http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk > > ----- Original Message ----- > | From: "Bernhard Pieber" <bernhard(a)pieber.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, April 23, 2012 9:53:35 AM > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk > | > | Hi GÃ¶ran, > | > | Thanks for your question! I have posted the announcement of the > | Styled Text Editor to the Pharo list as well because I still have > | not given up on the idea to port it to Squeak and Pharo. It is not > | straightforward but I consider it possible. > | > | Currently the Styled Text Editor is an external package which is > | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis > | so to port it alone is probably too much effort. What I think can be > | done is the following: > | Split Cuis into three parts, > | a) the parts which are not needed for Styled Text Editor, like the > | Cuis tools > | b) the parts of Cuis Morphic the Styled Text Editor depends on â this > | is in my opinion the most valuable part of Cuis because Juan spent > | years cleaning it > | c) the Smalltalk kernel below > | > | The idea is to port only part b) and the Styled Text Editor. And it > | has to be done automatically by a tool which creates packages for > | Squeak and Pharo, always from the latest code base. In addition you > | will probably need small Cuis portability packages done manually, > | one for Squeak and one for Pharo. > | > | Being able to always load the latest code base of Styled Text Editor > | and Cuis Morphic as an external package in Pharo is a prerequisite > | to look into possibilities of sharing more of the code. > | > | I plan to write a more detailed proposal and then to approach ESUG > | and ask for support for the funding. Any ideas for other sources of > | funding are highly welcome and could speed things up considerably, > | of course! ;-) > | > | I for one have not given up on the idea that it might be possible to > | develop substantial components as you called it â thank you for that > | as well â in a more Squeak-dialect-independent way. ;-) > | > | Finally, I would like to take the opportunity and kindly ask everyone > | who has not done so yet: Please check out Cuis 4.0 and the Styled > | Text Editor and give us feedback, even if it does not (yet) run on > | your favourite Squeak dialect! Thank you! > | > | Peace, > | Bernhard > | > | P.S. Thanks to GÃ¶ran and Janko for trying to establish different > | threads for the rather off-topic discussions that my announcement > | posting has caused. > | > | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: > | > Hi! > | > > | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: > | >>> Just cloning it off into Pharo and forking seems... less optimal. > | >>> Any ideas or thoughts? > | >> > | >> I do not get what you mean. I just want to work on our roadmap and > | >> make it getting real. > | >> It is hard enough to get some momentum and to deliver for real. > | >> So can you help us to get focused? > | >> People can do what they want. I wrote a vision document. We have a > | >> roadmap > | >> and we will do it. > | > > | > Ok, let me clarify. I was just wondering how the Pharo community > | > wants to handle a case where a substantial component (in this > | > case, this new editor) is not *primarily* developed in Pharo (in > | > this case Cuis). > | > > | > The simple route is to just copy and fork. But IMHO this doesn't > | > leverage the team already around this editor, right? We (Pharo) > | > can't just go around and forking everything and maintaining > | > everything for ourselves, right? > | > > | > I just got interested in that problem - now, later replies > | > indicated that it would still need a substantial rewrite for > | > Pharo, so perhaps the situation I am describing is not really > | > applicable in this case. > | > > | > regards, GÃ¶ran > | > > | > | > | > -- Best regards, Igor Stasenko.

13 72

Re: [Pharo-project] Have you played with Ameba?
by Fernando Olivero April 25, 2012

April 25, 2012

Nice indeed! Are you using a kind of spring layout for the big bang animation? Fernando On Mon, Dec 19, 2011 at 2:38 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 17, 2011, at 8:40 AM, HwaJong Oh wrote: > >> Markus, >> >> Forget Ameba. Ani is here. >> >> Zini das Wuslon is implemented. It moves like a real one. >> > > Very nice! > > Â Â Â Â Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

3 3

[Pharo-project] AnnotationPanePlugin for Nautilus
by Mariano Martinez Peck April 25, 2012

April 25, 2012

Hi Igor/Ben. I don't know if it was the correct path, but I commited NautilusCommon-MarianoMartinezPeck.58 which adds a new plugin: AnnotationPanePlugin. It is based on Igors one and taken the class from OB. For me this is really usful beacuse it shows for each method its author, timestamp, mcz version, category, number of implementors, etc. It does not show the number of senders because it is slow. So...is that fine? ahh btw, if you wonder how to do a script to enable plugins: Nautilus pluginClasses add: { AnnotationPanePlugin. #middle } cheers, -- Mariano http://marianopeck.wordpress.com

4 5

Re: [Pharo-project] [update 2.0] #20009
by Fernando Olivero April 24, 2012

April 24, 2012

great! We should say our farewells to BlockContext and SourceReference, amongst others... On Tue, Apr 24, 2012 at 6:20 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20009 > ----- > > Issue 5564: Â Â Support bit operations on Boolean / Integers > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5564 > > Issue 5641: Â Â Unload Deprecated14 > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5641 > > > > -- > Marcus Denker -- http://marcusdenker.de > >

1 0