- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN 1.1] pre-build Core#11357 pre-Freeze3

by Marcus Denker

https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 13, 2010

[Pharo-project] Iliad 0.8.1 released

by Nicolas Petton

Hi, We just released Iliad 0.8.1. This is a bug fix release with small improvements. Especially, we fixed an annoying bug related with session expiration, and improved Formula with global conditions and errors. The Comet API changed a bit too, you can read a blog post about it: http://smalltalk.gnu.org/blog/nico/iliad-applications-comet We also removed all hard-coded javascript generated in HTML pages. The javascript layer is now entirely responsible for automatic AJAX. We encourage everyone using Iliad 0.8 to upgrade to 0.8.1. - GNU Smalltalk There are now 2 git repositories and GNU Smalltalk projects, one for the stable branch and another one for the development branch. gst-package --download iliad -t ~/.st #latest stable release gst-package --download iliad-dev -t ~/.st #development branch The git repository for the stable branch can be browsed at: http://github.com/NicolasPetton/iliad-stable - Pharo Pharo users can install Iliad 0.8.1 with Metacello as explained on this page: http://www.iliadproject.org/pages/Download/Squeak-Pharo-port Cheers, Nico

May 13, 2010

Re: [Pharo-project] Preparing Pharo-Core for i18n framework

by StÃ©phane Ducasse

ok I will have a look now. Stef On May 13, 2010, at 12:00 PM, Hilaire Fernandes wrote: > To be compatible with the gettext package I have pushed in Inbox Collection-Strings and System-Localization changes. > > After the changes, NaturalLanguageTranslator becomes in core a dummy class responding to two dummy messages. This dummy class is later replaced by the real one when the developer loads the gettext package > > String>>translate reflect this change. > > I really don't know how to load these two package in Pharo without breaking the image. The only possibility I see is to first hand edit String>>translated to respond self, then load System-Localisation and Collection-String from Inbox. > > Tiny hand edit. > > We should get this tiny changes in as the Seaside people seems to need it as well. > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 13, 2010

Re: [Pharo-project] Preparing Pharo-Core for i18n framework

by StÃ©phane Ducasse

Ok can you open bug entry ticket else we cannot follow On May 13, 2010, at 12:11 PM, Hilaire Fernandes wrote: > Also I suggest to remove the LanguageEditor from the image. > > Hilaire > > Hilaire Fernandes a Ã©crit : >> To be compatible with the gettext package I have pushed in Inbox Collection-Strings and System-Localization changes. >> After the changes, NaturalLanguageTranslator becomes in core a dummy class responding to two dummy messages. This dummy class is later replaced by the real one when the developer loads the gettext package >> String>>translate reflect this change. >> I really don't know how to load these two package in Pharo without breaking the image. The only possibility I see is to first hand edit String>>translated to respond self, then load System-Localisation and Collection-String from Inbox. >> Tiny hand edit. >> We should get this tiny changes in as the Seaside people seems to need it as well. >> Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 13, 2010

Re: [Pharo-project] apparently recentMessages does not get the latest changes after

by StÃ©phane Ducasse

yes! Sorry On May 13, 2010, at 11:56 AM, Igor Stasenko wrote: > did you meant 'recent submissions'? > > On 13 May 2010 12:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> strange.... >> Any idea? >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 13, 2010

[Pharo-project] [update 1.1] #11358

by StÃ©phane Ducasse

11358 ----- - Issue 1097: Older Complex code breaks assumptions. remove complex class. Stef

May 13, 2010

Re: [Pharo-project] Remove developing with Pharo

by Henrik Sperre Johansen

On 12.05.2010 20:13, Andrei Stebakov wrote: > That's right, looks like it sends full-blown images (not the delta, > not the commands to x-server) and re-drawing takes forever. I wonder > if it's a Pharo issue or x-server's? My xterm works pretty fast > compared to Pharo though... AFAIK, this is a consequence of the rendering method used in Squeak/Pharo image/VM's. If I've understood the Mac platform-rendering code correctly, the way it works, is that a special Display bitmap is kept accessible to both image and VM. When rendering image side, all draws end up on the Display bitmap. (Using bitBlt as a context, rather than using f.ex. a HostGraphicsContexts to draw using the equivalent x-server/quartz/directDraw commands) Then, when it comes time to actually display, the VM takes the registered damage rects, and sends the contents of the Display bitmap in those areas for display. (In the Mac VM, this is actually folded down to one of 16 regions which are marked dirty or not, not sure how it works on other platforms). So yes, full-blown images is ever only sent. The advantages I can see is that: 1. All rendering logic is actually written in smalltalk. (Well, as part of the platform-independent, compiled-to-C VM sources at least) 2. It will render exactly the same on all platforms, due to #1. 3. The platform support code for rendering is really simple, all you need is the ability to display bitmap regions to the screen. Cheers, Henry.

May 13, 2010

Re: [Pharo-project] Preparing Pharo-Core for i18n framework

by Hilaire Fernandes

Also I suggest to remove the LanguageEditor from the image. Hilaire Hilaire Fernandes a Ã©crit : > To be compatible with the gettext package I have pushed in Inbox > Collection-Strings and System-Localization changes. > > After the changes, NaturalLanguageTranslator becomes in core a dummy > class responding to two dummy messages. This dummy class is later > replaced by the real one when the developer loads the gettext package > > String>>translate reflect this change. > > I really don't know how to load these two package in Pharo without > breaking the image. The only possibility I see is to first hand edit > String>>translated to respond self, then load System-Localisation and > Collection-String from Inbox. > > Tiny hand edit. > > We should get this tiny changes in as the Seaside people seems to need > it as well. > > Hilaire

May 13, 2010

[Pharo-project] [update 1.1] #11357

by StÃ©phane Ducasse

11357 ----- - Remove isolatedProject from changeset - Issue 2396: Added Dictionary>>#at:ifPresent:ifAbsent:. - Issue 2373: Unknown variable in CodeMorph - Issue 2383: createInstVarAccessors does not produce stupid comments Stef

May 13, 2010

[Pharo-project] Preparing Pharo-Core for i18n framework

by Hilaire Fernandes

To be compatible with the gettext package I have pushed in Inbox Collection-Strings and System-Localization changes. After the changes, NaturalLanguageTranslator becomes in core a dummy class responding to two dummy messages. This dummy class is later replaced by the real one when the developer loads the gettext package String>>translate reflect this change. I really don't know how to load these two package in Pharo without breaking the image. The only possibility I see is to first hand edit String>>translated to respond self, then load System-Localisation and Collection-String from Inbox. Tiny hand edit. We should get this tiny changes in as the Seaside people seems to need it as well. Hilaire

May 13, 2010