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

[Pharo-project] Redline Smalltalk and Pharo ....

by James Ladd

We are ensuring that Pharo code can run unmodified on Redline Smalltalk. This is exciting to us as recently Redline Smalltalk was deployed to the cloud on Heroku. We think Redline and Pharo opens up new possibilities. To do more we need your help, and ask you to support Redline Smalltalk with a donation here: http://www.indiegogo.com/smalltalk/x/1366536 Any Smalltalk that becomes more popular helps every Smalltalk. - James.

Dec. 5, 2012

Re: [Pharo-project] An excellent news

by Luc Fabresse

Thanks INRIA and of course thanks Igor for all his work and congrats to him ;-) #Luc 2012/12/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > >> Consortium membership is in the mail > > Thanks. > the beta website on the way. > > > > > Stephan > > > > >

Dec. 5, 2012

Re: [Pharo-project] An excellent news

by StÃ©phane Ducasse

>> Consortium membership is in the mail Thanks. the beta website on the way. > > Stephan >

Dec. 5, 2012

Re: [Pharo-project] PharoConf 2013 @ Bern?

by StÃ©phane Ducasse

On Dec 5, 2012, at 6:50 PM, Hilaire Fernandes wrote: > Hello, > > So during the week days 4/4 to 8/4 ? No 2-3-4 April. or 2 and 3 of april Stef > > Hilaire > > > Le 05/12/2012 09:44, StÃ©phane Ducasse a Ã©crit : >> Hello Pharoers >> >> The software composition group of the university of Bern proposed to organize the next pharo conf at berne during the week >> of 2-3 of April 2013. We are really happy of this proposal. Now we would like to know what you think about it >> before committing to the date and location. >> >> The Pharo board and crew >> > > >

Dec. 5, 2012

Re: [Pharo-project] Vim Keys?

by StÃ©phane Ducasse

On Dec 3, 2012, at 9:30 AM, Goubier Thierry wrote: > Le 01/12/2012 18:59, StÃ©phane Ducasse a Ã©crit : >> What we want is to clean all the hardcoded short cut and rethink all the them using key mapper >> Then people can define some maps and install them at wish. > > TextMorph apart, this is not that difficult and it can be done Morph by Morph without disrupting the system... Volunteers, please! > > (I did it for SimpleHierarchicalListMorph and that has been integrated, but I now noticed I haven't finished removing the old, hardcoded shortcuts code :( ). > >> For example I miss end of line start of line (emacs like :)). >> I would like to have esc esc to select an expression >> so that I can do esc esc + cmd D and get done :) >> >> Stef > > Any suggestions on a global scheme for user-configurable keycaps ? I will discuss with guillermo about that because this is time to really tart to do it for 3.0 Right now I will focus on fixing 20 bugs Stef > > Thierry > -- > 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 >

Dec. 5, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by StÃ©phane Ducasse

> > I would go so far as to say comments in tests are *especially* important. > It's sometimes hard to tell whether a failure is due to a faulty test, or an actual bug, when you have no idea (even when looking at the code) what case the test was actually written to cover. > With a comment of what the test was intended to do, you have a better feel for how to handle it. > > TL;DR: Intent, while obvious to whoever is writing the test, may not be so clear to whoever is around when it starts failing. > > Cheers, > Henry +1 >

Dec. 5, 2012

Re: [Pharo-project] using a long running native thread - NativeBoost or Plugin?

by Igor Stasenko

On 2 December 2012 23:59, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Would it be possible to start native thread inside pharo? This thread would > run (for quite a long time) some event loop (like the libev), and post some > info to the SharedQueue. Smalltalk code would in turn be reading stuff from > this queue. You could say it would be pumping events from libev to > SharedQueue instance for Smalltalk code to consume. > > Is this doable? With NativeBoost or Plugin? > > I have also found some info on threaded VM, but if I understand it correctly > it seems more oriented to provide a thread to execute FFI call on it. > I have a prototype for worker thread loop implemented in NB.. The idea is to call some function in that thread and then signal a semaphore when call complete. And of course making VM thread to be 'owned' by non-main thread needs to be supported. The main problem with this approach is that some primitives/functions has to be invoked in main thread.. and to control that, it will require some work in VM/language side to fulfill such requirement. The hard part of it, that we have barrier between language and VM, and lack of coordination to manage and correct usage of native threads. -- Best regards, Igor Stasenko.

Dec. 5, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by StÃ©phane Ducasse

On Dec 4, 2012, at 12:57 PM, Sven Van Caekenberghe wrote: > But I think we do agree ;-) > > What makes me value tests a bit above documentation (but not so much that I am saying that documentation is not important), are two things: > > - tests are machine enforceable/controllable > - you can find them exactly using senders or references sure I still want somebody to help with <testForDocumentation> idea. so that some tests are added to the documentation of package Stef > > On 04 Dec 2012, at 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right >> I will explain you why. >> >> Even writing comment in test is cool. >> >> Stef >> >>> Well written: >>> >>> http://kennethreitz.org/open-source-and-constraints.html >>> >>> I also find that writing documentation (minimal method/class comments or longer standalone documents) improves coding, because you take another perspective. I wouldn't value it above tests though. >>> >>> Sven >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >> > >

Dec. 5, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Camillo Bruni

=> Xtreams and Pharo 3.0 ;) I think anything else is a major waste of time :P On 2012-12-05, at 14:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > one day we will have to address the old streams :) > > > On Dec 3, 2012, at 9:44 PM, Sven Van Caekenberghe wrote: > >> >> On 03 Dec 2012, at 19:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Yes, the lack of FileStream buffering was (re)-discovered and >>> corrected when I have experimented with my own SqueaXTream experiments >>> http://www.squeaksource.com/XTream/ before porting the original >>> Xtreams to Squeak http://www.squeaksource.com/Xtreams/ >>> Then Levente soon came up with an excellent patch for buffering Squeak >>> FIleStream and this was later ported to Pharo. >>> >>> What I also re-discovered is that not only buffering the raw file >>> counts, but also buffering the decoding. >>> Indded, an uncarefull implementation would read file by chunk but >>> decode byte after byte... >>> While a buffered one would decode large chunks of ASCII (if any) in a >>> single copy primitive. >>> >>> This was reported near the end of this post: >>> http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/151341 >>> >>> For Xtreams, I don't remember exactly where I put some experiments, >>> but pre-allocating a WideString instead of a String can also make a >>> noticeable difference in presence of WideCharacter... >> >> Many people seem to be rediscovering the same problems, not a good sign ;-) >> >> I think that in particular MultiByteFileStream>>#peek is not efficient. >> >> Yeah, there seems to be a WideString construction issue as well, I haven't looked into it yet. >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > >

Dec. 5, 2012

Re: [Pharo-project] [Pharo-users] Legacy FileDirectory

by StÃ©phane Ducasse

thanks camillo Stef On Dec 4, 2012, at 11:20 PM, Camillo Bruni wrote: > I finally found the motivation to properly package my compatibility package. > > http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy > > For people who want to migrate to 2.0 but depend on FileDirectory, they can > load this compatibility package for 2.0 which will add a mock FileDirectory. > It will mostly forward to FileReference. > > This is legacy software and should only be used for migration ;) > > best > cami >

Dec. 5, 2012