June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [Seaside] Comparison of Aida/Web, Seaside and Iliad web frameworks

by StÃ©phane Ducasse

what's the problem with the last item? :) Stef On Jun 22, 2011, at 1:50 PM, Sven Van Caekenberghe wrote: > This was posted on the Seaside mailing list, I think it is both funny and hitting several points. > > I am not sure about the last item though ;-) > > Sven > > Begin forwarded message: > > On 22 Jun 2011, at 04:58, Boris Popov, DeepCove Labs wrote: > >> http://dl.dropbox.com/u/2737880/screenshots/pharovsvisualworks.png >> >> <image001.png> >> >

June 22, 2011

[Pharo-project] Zodiac Alpha - June 21, 2011

by Sven Van Caekenberghe

A number of people have been asking for an easy/convenient way to test Zodiac, an as yet unfinished attempt at a better (secure) socket stream, in order to support HTTPS. I uploaded a 16Mb archive with a ready made image and a Mac OS X Cog VM with the necessary plugin: http://homepage.mac.com/svc/Zodiac-Alpha-June-21-2011.zip Make sure to use the included VM called 'Pharo' by dropping the zodiac.image on it. Sven PS: Sorry, but Linux and Windows VM's don't fully work right now, I will look into this when I have more time. ------------------------------------------------------------ "Start with a plain Pharo Core 1.2.1 #12345" Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; package: 'Zinc-Patch-HTTPSocket'; load. Gofer it squeaksource: 'Zodiac'; package: 'Zodiac-Core'; package: 'Zodiac-Tests'; load. Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-Zodiac'; load. "Switch to the Zn Zodiac socket factory" ZnNetworkingUtils default: ZnZodiacNetworkingUtils new. "Note: all http(s) in the image will now go through Zodiac streams" "** Make sure to use a Mac OS X Cog VM with the SSL plugin **" "Run the units tests, or just try" ZnClient get: 'https://encrypted.google.com'.

June 22, 2011

Re: [Pharo-project] focus morph

by Hilaire Fernandes

Yes, your suggestion works out of the box, but it is sad it is too much magic looking like. I had a note on the collaborative pharo book. Is there some magic to set focus on mouse clic? Or is it just about handling mouse clic and set the focus? Thanks Hilaire Le 22/06/2011 16:30, Hilaire Fernandes a Ã©crit : > Thanks, great info! > > > Le 22/06/2011 16:24, Gary Chambers a Ã©crit : >> Additionally, you need to respond true to #handlesKeyboard: >> Otherwise the Morphic event dispatcher won't send a keystroke. >> >> Mostly though you'll need to implement: >> >> keyboardFocusChange: aBoolean >> "The message is sent to a morph when its keyboard focus changes. >> Update for focus feedback." >> >> self focusChanged >> >> >> +and >> >> drawSubmorphsOn: aCanvas >> "Display submorphs back to front. >> Draw the focus here since we are using inset bounds >> for the focus rectangle." >> >> super drawSubmorphsOn: aCanvas. >> self hasKeyboardFocus ifTrue: [self drawKeyboardFocusOn: aCanvas] >> >> >> +and >> >> keyStroke: event >> "Process keys navigation and space to toggle." >> >> (self navigationKey: event) ifTrue: [^self]. >> "your key handlers here if any..." >> >> in order to have the focus drawn and handle tab/shift-tab navigation >> between morphs. >> >> Sorry it is less than simple, just the way Morphic is (unless we >> refactor focus stuff to be potentially applicable to all morphs). >> >> Regards, Gary >> >> ----- Original Message ----- From: "Hilaire Fernandes" >> <hilaire.fernandes(a)edu.ge.ch> >> To: <pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, June 22, 2011 2:56 PM >> Subject: [Pharo-project] focus morph >> >> >>> Hello, >>> >>> In a panel morph I have a collection of morph, I want the focus features >>> on these morphes. >>> >>> morphs of the collection respond true to the takesKeyboardFocus message >>> but so far it does not help. >>> >>> >>> What is the usual way to do that? >>> >>> >>> -- >>> Education 0.2 -- http://blog.ofset.org/hilaire >>> >>> >> >> >> > > -- Education 0.2 -- http://blog.ofset.org/hilaire

June 22, 2011

[Pharo-project] [COTDC] 75 - MorphTreeNavigationBar

by laurent laffont

Today: MorphTreeNavigationBar Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

June 22, 2011

Re: [Pharo-project] [COTDC] 74 - MorphTreeNodeMorph

by laurent laffont

On Tue, Jun 21, 2011 at 10:16 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > Today: MorphTreeNodeMorph > I draw the node part of a tree. Laurent. > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

June 22, 2011

Re: [Pharo-project] Athen, Cairo, Paris, Santiago, ...

by Igor Stasenko

On 22 June 2011 22:24, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Rendering in Mondrian is now externalized into visitors. It should be pretty straightforward to write one for cairo > Athens has initially layered structure. The frontend you will be using (canvas , surfaces, etc) is implementation neutral. So, swapping a backend who doing the real work, will cost nothing from users perspective. > Alexandre > > > On 22 Jun 2011, at 15:21, Igor Stasenko wrote: > >> On 22 June 2011 22:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> Hi! >>> >>> Just wondering what is the status of Athen / Cairo for Pharo? We recently put some effort on exporting Mondrian visualization to HTML/Protovis to benefit from vectorial graphics... >>> >> >> Status: "Under development" >> >> :) >> >> It can draw almost everything morphic-related, except one little thing - text :) >> And now i'm on crossroads , what to do. >> Clearly, a StrikeFont(s) is state as they now, simply don't fit with >> scalable vector graphics engine. >> The bitmaps stored in memory are optimized for exact fit 1:1 of >> display pixel grid. >> So, at minimum it will require converting all fonts to use different >> bitmaps, before they can be drawn using Athens canvas. >> >> Another thing is drawing strokes. It is a question how far i should go >> implementing a basic (and most probably fall-back) engine which using >> old BallooonEngine, >> which can only draw a coarse, barely anti-aliased strokes. Not saying >> it doesn't supports many things, like joint types, dashing , masking >> etc etc. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- Best regards, Igor Stasenko AKA sig.

June 22, 2011

Re: [Pharo-project] Athen, Cairo, Paris, Santiago, ...

by Alexandre Bergel

Rendering in Mondrian is now externalized into visitors. It should be pretty straightforward to write one for cairo Alexandre On 22 Jun 2011, at 15:21, Igor Stasenko wrote: > On 22 June 2011 22:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> Just wondering what is the status of Athen / Cairo for Pharo? We recently put some effort on exporting Mondrian visualization to HTML/Protovis to benefit from vectorial graphics... >> > > Status: "Under development" > > :) > > It can draw almost everything morphic-related, except one little thing - text :) > And now i'm on crossroads , what to do. > Clearly, a StrikeFont(s) is state as they now, simply don't fit with > scalable vector graphics engine. > The bitmaps stored in memory are optimized for exact fit 1:1 of > display pixel grid. > So, at minimum it will require converting all fonts to use different > bitmaps, before they can be drawn using Athens canvas. > > Another thing is drawing strokes. It is a question how far i should go > implementing a basic (and most probably fall-back) engine which using > old BallooonEngine, > which can only draw a coarse, barely anti-aliased strokes. Not saying > it doesn't supports many things, like joint types, dashing , masking > etc etc. > > -- > Best regards, > Igor Stasenko AKA sig. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 22, 2011

Re: [Pharo-project] Athen, Cairo, Paris, Santiago, ...

by Igor Stasenko

On 22 June 2011 22:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Just wondering what is the status of Athen / Cairo for Pharo? We recently put some effort on exporting Mondrian visualization to HTML/Protovis to benefit from vectorial graphics... > Status: "Under development" :) It can draw almost everything morphic-related, except one little thing - text :) And now i'm on crossroads , what to do. Clearly, a StrikeFont(s) is state as they now, simply don't fit with scalable vector graphics engine. The bitmaps stored in memory are optimized for exact fit 1:1 of display pixel grid. So, at minimum it will require converting all fonts to use different bitmaps, before they can be drawn using Athens canvas. Another thing is drawing strokes. It is a question how far i should go implementing a basic (and most probably fall-back) engine which using old BallooonEngine, which can only draw a coarse, barely anti-aliased strokes. Not saying it doesn't supports many things, like joint types, dashing , masking etc etc. -- Best regards, Igor Stasenko AKA sig.

June 22, 2011

[Pharo-project] Athen, Cairo, Paris, Santiago, ...

by Alexandre Bergel

Hi! Just wondering what is the status of Athen / Cairo for Pharo? We recently put some effort on exporting Mondrian visualization to HTML/Protovis to benefit from vectorial graphics... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 22, 2011

[Pharo-project] PharoKernel 13269

by Igor Stasenko

oops, forgot CCs. On 22 June 2011 20:07, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > On Tue, Jun 21, 2011 at 12:29 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> what we should pay attention (to be verified) is that igor told me that he >> does not understand why >> the latest code of the vm published by eliot does not include some fixes >> he did for 1.2. May be the code was never integrated. >> In addition the latest vm produced by eliot does not include a long list >> of fixes made by igor and mariano. >> Igor asked in the vm mailing-list what will happen to his changes and >> there were no reaction so far. > > I feel some ownership of the Cog branch. Â It would be nice to have a chance > to review code before it gets in instead of having to merge. Â You might > think of sending me changesets for the more complex sets of changes (e.g. > finalization) so that the merge is easier. Â Finally, you might understand > that I'm busy at work and for personal reasons have essentially no time at > the weekends to work on Cog. The code are available for you at VMMaker repository. It is hardly an excuse that you cannot review it in such form. Because you are working with MC (i seen that) and i bet that you know it good enough to compare two snapshots and do the merge. Concerning changesets, etc etc.. i pointed to code with new finalization to you multiple times, in multiple forms (.cs , .mcz ) and reminded dozen times. Still , as of now, these 2 methods change + 1 additional class var are still not in main cog branch (by main i consider one which are released by you). So, how does these facts correllating with what you stated above? Also, let me remind you that first two letters in OSCog stands for open source, which means that this project are open source and no single person can own it. It is owned by comminity, by definition. And while i really like if you (or anybody else) can spend his time reviewing my code, it doesn't means that all contributions should come through single person, since it creates an unnecessary bottleneck in development process. And actually current experience shows how it is bad to have such bottlenecks. So, if you want to own your project, it is fine - keep your own private copy of Cog somewhere but don't call it public. >Â Criticising me in public like this does not > make me any more eager to find the time. Ignoring my contributions don't makes me more eagier to do anything as well. Continuously, i feel like i am at a noise level for you, which you constantly ignoring. Because you often reacting to contributions from others and swiftly integrating them, but not mine. It looks like i am black listed, or you have a noise filter.. since nothing i did (which i consider important) are in your VMs. Maybe i deserve to be at a noise level, and all my work not worth a single penny. Just say it. Make it clear. Because ignoring is a worst choice. >> >> So we should pay attention that using the latest vm from eliot may also >> break our system. We should also think about the fact that >> may be we will have to burn igor's time to merge vm fixes when other >> people don't do it. >> I asked igor to continue to work on the windows build because we want to >> run regression tests at the VM level. We should be able to trace >> vm changes and control the impact they have on us and not run after >> different versions and releases. To have a process in a sense. >> >> Stef >> >> yeah.. harmonization, it would be good, Eliot if you take a look of >> changes made in >> VMMaker-oscog-MarianoMartinezPeck.66 >> and integrate them, so we will use common version. >> >> They have a common ancestor - >> VMMaker-oscog.54 >> >> Without this all of the following work will be lost: >> >> Name: VMMaker-oscog-IgorStasenko.54 >> Author: IgorStasenko >> Time: 23 March 2011, 5:30:42 pm >> UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae >> Ancestors: VMMaker-oscog-IgorStasenko.53 >> >> - added disabling module loading support >> >> >> Name: VMMaker-oscog.dtl.56 >> Author: dtl >> Time: 4 April 2011, 10:06:00.292 pm >> UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 >> Ancestors: VMMaker-IgorStasenko.55 >> >> Add tests from VMMaker trunk to document various issues and verify >> presence of primitives. >> >> Name: VMMaker-oscog.dtl.57 >> Author: dtl >> Time: 11 April 2011, 10:13:51.668 pm >> UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 >> Ancestors: VMMaker-oscog.dtl.56 >> >> Generate C code for #repeat. >> Implementation by Igor Stasenko and Nicolas Cellier. > > That's already integrated. > Not. As i seen in your latest snapshot, an " Â added disabling module loading support " not there as well as a better finalization scheme i implemented YEAR ago and its already used in our images. Just evaluate WeakFinalizationList hasNewFinalization in your image under VMs you built. Now, with such approach, i feel very afraid, how much time it would take for integrating Ephemerons, which i implemented, and would really like to be reviewed by you. If 2 methods change taking almost a year to integrate.. then this could take 5 years.. or not be integrated at all. >> >> Name: VMMaker-oscog-dtl.58 >> Author: dtl >> Time: 17 April 2011, 10:22:12.174 pm >> UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 >> Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57 >> >> Merge VMMaker-oscog.dtl.57 >> >> Generate C code for #repeat. >> Implementation by Igor Stasenko and Nicolas Cellier. > > ditto. > >> >> Name: VMMaker-oscog-dtl.59 >> Author: dtl >> Time: 17 April 2011, 10:32:55.018 pm >> UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 >> Ancestors: VMMaker-oscog-dtl.58 >> >> Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion > > Since there's a VM parameter I question the need for yet-another-primitive. > >> >> Add primitiveMillisecondClockMask, an optional named primitive used in >> conjunction with primitiveMillisecondClock for duration calculations. >> The image assumes a value for this constant that is assumed to >> correspond to the actual value used in the VM. This primitive permits >> the VM to report the actual value being used. > > Already integrated. > >> >> Add primitiveImageFormatVersion, an optional named primitive answering >> the image format number of the current image. This is the value stored >> in the first word of an image file header when the image is saved, and >> possibly modified on image load if the VM adds or removes capabilities >> for the running image. This primitive was added to VMMaker trunk in >> VMMaker-dtl.169. Rationale: supports float word order handing for >> image segments, reference >> http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html > > Not integrating this. Â The VM parameter (41) has been in Cog since the > beginning. Â Instead why not merge the VM parameter back into Interpreter? > Maybe i missed a discussion, where you stating that? Btw, i really prefer symbolic names rather than numbers. Because it is easier to remember, easier to handle and less confusing. So, on one hand we have an extra primitive with clear name, which states what it does, on another hand we having a magic number '41' (btw, why not 42, i like it more? ;) ), which says NOTHING. Guess, which side wins? But of course this single difference is not very significant. Unless we approach to this systematically (use symbolic names instead numbers), which i would really prefer to have. [snip] -- Best regards, Igor Stasenko AKA sig.

June 22, 2011