- Pharo-dev - lists.pharo.org

[Pharo-project] 11254 Image available
by StÃ©phane Ducasse March 9, 2010

March 9, 2010

Hi guys sorry for the fact that some of you could not update anymore due to a stupid name for package (we should check that : space ; / cannot be put in the package name. https://gforge.inria.fr/frs/download.php/26637/PharoCore-1.1-11254-UNSTABLE… Stef

2 2

[Pharo-project] FieldNode
by Pavel Krivanek March 9, 2010

March 9, 2010

Hi, I suppose that the class FieldNode should be removed. It is a Tweak hack: "FieldNode handles field access in Tweak, e.g. self fieldName := foo => self fieldName: foo." it is used only in Encoder >>Â #init:context:notifying: where it supposes nil offset. There's no such case in Pharo. Cheers -- Pavel

2 1

Re: [Pharo-project] [Moose-dev] Re: XML Parser / Pastell
by Alexandre Bergel March 9, 2010

March 9, 2010

NB: I switch to Pharo > Normally when you want to deprecate a method and discourage people > from using it you need only insert a "self deprecated: description" > line into it. When someone invokes such a method, they receive a > warning of its deprecation listing specifically its name and class. Yep, I understand this. Apparently, SAXDriver>>handleStartTag:attributes:namespaces: (indirectly) calls #startElement:attributes:, a deprecated method. Do you think we should update handleStartTag:attributes:namespaces: ? Also, the method SAXHandler>>startElement:prefix:uri:attributes: is not covered by the test. I think it is important that this method is covered. Cheers, Alexandre > I wanted to rename some of the handler messages in SAXHandler so > they would be more consistent with each other (note, for example, > the different argument order between > #startElement:namespaceURI:namesapce- and > #endElement:namespace:namespaceURI-) and also with other parts of > the API (-attributeList: vs. -atttributes:). Unfortunately, there is > no easy way to deprecate such messages. Users do not send them; > instead they override them in subclasses and expect the overridden > versions to be invoked by SAXDriver. Another problem is that the > handlers must degrade in a specific order, with each form invoking > the one taking the most arguments after it until the one taking the > fewest arguments (e.g., #startElement:attributes:) is reached. > > That unusual #forwardToDeprecatedHandler:withArgumentOrder:orTo: > message you discovered is the ad hoc solution. In renamed handlers > it checks to see if the old, deprecated version is implemented in > the class of the receiver and if it is, warns that it has been > deprecated and suggests using the new form--the caller--prior to > invoking the old form with the caller's arguments (reordered if > needed). If the deprecated version is not present, then it either > degrades in the normal fashion, invoking the version taking next- > most arguments after itself (which may also check for a deprecated > version of itself) or do nothing if no other handler needs to be > invoked. > >>> >>> The most recent version is completely string-based. The performance >>> of the symbol-based predecessors was erratic; it would be terribly >>> slow at first in a clean image and improve only after saving the >>> image at least once. Even then my tests indicated that a purely >>> string-based version would be faster. This is likely due to the >>> initial overhead of interning symbols and then the subsequent >>> overhead of looking them up. I did honestly prefer the #symbol >>> syntax for naming things, but considering that the things so-named >>> and the names themselves all begin life (from the tokenizer) as >>> strings, it makes more sense (and requires less code) to keep them >>> that way. It is also more portable, as we no longer need assume that >>> Symbol is a subclass of String. I don't think this will cause issues >>> in Squeak/Pharo code, as both systems (for now) assume #name = >>> 'name'. Hopefully it will not cause too much trouble for Norbert. >>> >>> Alexandre, you should see an improvement in your benchmarks now. >> >> Indeed! >> Cool! >> >> Alexandre >> >>> >>>>>>> anElement attributes class (I wrote species but that will fail >>>>>>> in >>>>>>> gemstone too I guess. Hell!) >>>>>> >>>>>> I just committed with species. Let me know. This is easy to >>>>>> adjust. >>>>>> >>>>> Ok. >>>>> >>>>>>>>> The gemstone XML Parser decides somehow to use >>>>>>>>> IdentityDictionary internally. I think this should be >>>>>>>>> allowed. I >>>>>>>>> just changed Dictionary to IdentityDictionary so the = test >>>>>>>>> reflects the right type. If you change it it is clear that it >>>>>>>>> fails. Because pharo uses Dictionary internally. So you might >>>>>>>>> see that it is not a question of using Dictionary or >>>>>>>>> IdentityDictionary but a question of the wrongness of using = >>>>>>>> >>>>>>>> How the XMLNodeTest should look like to accommodate your >>>>>>>> situation? >>>>>>>> >>>>>>> I need to recheck this. The problem is really that the XML >>>>>>> Parser >>>>>>> creatios instances of class Association but { #key->'value' } >>>>>>> creates an instance of class SymbolAssociation. That means I >>>>>>> would >>>>>>> know how to fix the test but I want to understand the >>>>>>> implications >>>>>>> of all of this. I'll get to you if I know anything new. >>>>>> >>>>>> Ok. >>>>>> >>>>> My mail to the gemstone list led to a ticket about removing class >>>>> checks from Association. That would be easing the handling a lot. >>>>> >>>>> Norbert >>>>>>> >>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>>> >>>>>>>>>>> Here there is an assumption about the allAttributes >>>>>>>>>>> collection >>>>>>>>>>> while using = as comparsion. But there is also an assumption >>>>>>>>>>> about the order of the content. I changed this to >>>>>>>>>>> >>>>>>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>>>>>>> 'A0000'). (#'family-name'->'Gates')}). >>>>>>>>>> >>>>>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>>>>>> the thing? Do you not test the size of the array. >>>>>>>>>> >>>>>>>>>>> This is not the best way to do because the check is only in >>>>>>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>>>>>> assert fails and I have to check what is going on here. >>>>>>>>>> >>>>>>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>>>>>> ordered. Would a asSortedCollection help? >>>>>>>>>> >>>>>>>>>> I have now granted you an access to the repository. You >>>>>>>>>> should >>>>>>>>>> be able to directly commit in it. >>>>>>>>>> >>>>>>>>>> Jaayer, what is your Squeaksource account? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Alexandre >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>>>>> >>>>>>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>>>>>> component. With the newest changes it became biased >>>>>>>>>>>>> towards >>>>>>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>>>>>> parser will depend on the squeak package which I don't >>>>>>>>>>>>> like. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Norbert, >>>>>>>>>>>> >>>>>>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>>>>>> wrote a small script that identify the squeak classes >>>>>>>>>>>> used in >>>>>>>>>>>> XML-Support. Here is the list: LanguageEnvironment, >>>>>>>>>>>> Unicode, >>>>>>>>>>>> LocaleID, CharacterSet >>>>>>>>>>>> >>>>>>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>>>>>> >>>>>>>>>>>> CharacterSet seems to be one that has to be ported. It is >>>>>>>>>>>> not >>>>>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>>>>>> whether this is useful in your case however. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Alexandre >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] Please: less license blahblah, more actual progress on the issue
by Paolo Bonzini March 9, 2010

March 9, 2010

On Mon, Mar 8, 2010 at 18:53, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > Thanks thanks thanks thanks for a refresh on that! > Thanks! Stef, instead of thanking five times, why don't you try to do something constructive? The GPLv3 includes a system of granting Additional Permissions. This system has already been used by GCC and Autoconf. Let's develop a set of additional permissions that we believe do not "taint" the whole image. I placed a starting point at http://smalltalk.gnu.org/blog/bonzinip/towards-permissive-copyleft-license-… [To those that followed the entire thread: this is totally independent of how any GSoC code related to GNU Smalltalk will be licensed]. Paolo

2 1

[Pharo-project] More news about GSoC!!!
by Mariano Martinez Peck March 9, 2010

March 9, 2010

Hi folks. We have been working hard with Janko and we built a website for the GSoC 2010 and for future editions! The URL is http://gsoc2010.esug.org/ In 4 days, is the deadline to submit ESUG as mentoring organization. For that purpose, there are several questions that we need to answer, as you can read here: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#… This is the most important step. If we get selected, then we have project, and we will have to vote which projects to select and finally select students...but all that is ONLY if we are selected as mentoring organization. Last year Squeak wasn't so this year will be hard. We really appreciate any feedback you can give us so that we can achieve this goal. Basically we should demonstrate that we have a big community, with several interesting projects and with mentors and students that are willing to do it. Our first version of those answer are here: http://gsoc2010.esug.org/application.html Please, send feedback. The ideas page is necessary. For this, it would be cool to have several projects. With this we can show that the community is big. Of course, we cannot put projects that has no sense. But don't be shy to submit. We are ALL smalltalk dialects and even Newspeak. Right now there are 13 projects but I think there can be much more. In squeak 2007 there were like 20, and now we are all dialects together. Note that a project doesn't need to be cross dialect. You can propose a project that apply only to one dialect. I cannot take the time to write each proposal...so, if you have a project, right the title, description, technical details, benefits to the student and benefits to the community. Otherwise will be probably ignored. It would be cool to have all mentors already selected for the 12th so that we can demonstrate that we are really willing to do it and that we already have mentors for all projects. Even more, it would be fantastic if there can be mentors or co-mentors. As you can see in the ideas link, there are ideas that are not even complete. No text. Again...if someone want to do it, excellent. Otherwise, they will have to be removed. Now...a personal question...do you think we have enough students to take care about the projects? what is your opinion ? That's all for the moment...please, if you have questions, just ASK!!! 4 days..... Cheers Mariano

2 4

Re: [Pharo-project] [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
by Paolo Bonzini March 9, 2010

March 9, 2010

On Tue, Mar 9, 2010 at 16:10, John O'Keefe <wembley.instantiations(a)gmail.com> wrote: > I am willing to co-mentor a Grease project and/or a portable TCPIP > implementation (we will need this for the OpenSSL project anyway). I can contribute the GNU Smalltalk TCP/IP implementation under whatever license. It's all written by me(*) so I can relicense it. (*) see http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f=packages/socke… UnixStream.st is not anymore part of the package, and Nicolas Burrus' work is not present anymore since I introduce IPv6 support. Paolo

1 0

Re: [Pharo-project] [Seaside] re: [vwnc] More news about GSoC!!! Some Idea
by Julian Fitzell March 9, 2010

March 9, 2010

Yes. Administrative tools for Seaside would be an excellent project. Julian On Tue, Mar 9, 2010 at 8:50 AM, Maarten MOSTERT <maarten.mostert(a)wanadoo.fr> wrote: > Mariano, > > This is a very good initiative ! > > I don't think what other peoples opinion is about this, but personnally I would appreciate if the base of Seaside > had some integrated statistics tools, registration of certain actions, info aout sessions etc. > Just an idea.. > > @+Maarten, > > >> Message du 09/03/10 01:13 >> De : "Mariano Martinez Peck" >> A : "Pharo Development" > , "The general-purpose Squeak developers list" > , "ESUG Members" , "Seaside - general discussion" > , "AIDA/Web general discussion list" , help-smalltalk(a)gnu.org, > vwnc(a)cs.uiuc.edu, beta(a)seaside.gemstone.com >> Copie Ã : >> Objet : [vwnc] More news about GSoC!!! >> >> Hi folks. We have been working hard with Janko and we built a website for >> the GSoC 2010 and for future editions! >> >> The URL is http://gsoc2010.esug.org/ >> >> In 4 days, is the deadline to submit ESUG as mentoring organization. For >> that purpose, there are several questions that we need to answer, as you can >> read here: >> http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#… >> >> This is the most important step. If we get selected, then we have project, >> and we will have to vote which projects to select and finally select >> students...but all that is ONLY if we are selected as mentoring >> organization. Last year Squeak wasn't so this year will be hard. We really >> appreciate any feedback you can give us so that we can achieve this goal. >> Basically we should demonstrate that we have a big community, with several >> interesting projects and with mentors and students that are willing to do >> it. >> >> Our first version of those answer are here: >> http://gsoc2010.esug.org/application.html >> >> Please, send feedback. >> >> The ideas page is necessary. For this, it would be cool to have several >> projects. With this we can show that the community is big. Of course, we >> cannot put projects that has no sense. But don't be shy to submit. We are >> ALL smalltalk dialects and even Newspeak. Right now there are 13 projects >> but I think there can be much more. In squeak 2007 there were like 20, and >> now we are all dialects together. Note that a project doesn't need to be >> cross dialect. You can propose a project that apply only to one dialect. >> I cannot take the time to write each proposal...so, if you have a project, >> right the title, description, technical details, benefits to the student and >> benefits to the community. Otherwise will be probably ignored. >> >> It would be cool to have all mentors already selected for the 12th so that >> we can demonstrate that we are really willing to do it and that we already >> have mentors for all projects. Even more, it would be fantastic if there can >> be mentors or co-mentors. >> >> As you can see in the ideas link, there are ideas that are not even >> complete. No text. Again...if someone want to do it, excellent. Otherwise, >> they will have to be removed. >> >> Now...a personal question...do you think we have enough students to take >> care about the projects? what is your opinion ? >> >> That's all for the moment...please, if you have questions, just ASK!!! >> >> 4 days..... >> >> Cheers >> >> Mariano >> >> >> [ (pas de nom de fichier) (0.1 Ko) ] > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

2 1

Re: [Pharo-project] [squeak-dev] Re: [Esug-list] More news about GSoC!!!
by Mariano Martinez Peck March 9, 2010

March 9, 2010

On Tue, Mar 9, 2010 at 7:42 AM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: > Mariano, > > As Stephane mentionned, my proposal is quite close the a prexisting one > related to parcel and fast code loading. > I would live we merge those two proposal in one better proposal. I don't > like much duplication when resources is quite limited. Do you think it is > possible? > > Yes, it is possible to merge. It is also possible to merge it after. I mean, once we get selected (if that happens), you can merge it. I tell you this so that not to loose too much time. On the other hand, if you want to do it now, perfect. Talk to Stef and send me a merged version and I upload the site. Cheers Mariano > Hilaire > > > 2010/3/8 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Hi folks. We have been working hard with Janko and we built a website for >> the GSoC 2010 and for future editions! >> >> The URL is http://gsoc2010.esug.org/ >> >> In 4 days, is the deadline to submit ESUG as mentoring organization. For >> that purpose, there are several questions that we need to answer, as you can >> read here: >> >> http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#… >> >> This is the most important step. If we get selected, then we have project, >> and we will have to vote which projects to select and finally select >> students...but all that is ONLY if we are selected as mentoring >> organization. Last year Squeak wasn't so this year will be hard. We really >> appreciate any feedback you can give us so that we can achieve this goal. >> Basically we should demonstrate that we have a big community, with several >> interesting projects and with mentors and students that are willing to do >> it. >> >> Our first version of those answer are here: >> http://gsoc2010.esug.org/application.html >> >> Please, send feedback. >> >> The ideas page is necessary. For this, it would be cool to have several >> projects. With this we can show that the community is big. Of course, we >> cannot put projects that has no sense. But don't be shy to submit. We are >> ALL smalltalk dialects and even Newspeak. Right now there are 13 projects >> but I think there can be much more. In squeak 2007 there were like 20, and >> now we are all dialects together. Note that a project doesn't need to be >> cross dialect. You can propose a project that apply only to one dialect. >> I cannot take the time to write each proposal...so, if you have a project, >> right the title, description, technical details, benefits to the student and >> benefits to the community. Otherwise will be probably ignored. >> >> It would be cool to have all mentors already selected for the 12th so that >> we can demonstrate that we are really willing to do it and that we already >> have mentors for all projects. Even more, it would be fantastic if there can >> be mentors or co-mentors. >> >> As you can see in the ideas link, there are ideas that are not even >> complete. No text. Again...if someone want to do it, excellent. Otherwise, >> they will have to be removed. >> >> Now...a personal question...do you think we have enough students to take >> care about the projects? what is your opinion ? >> >> That's all for the moment...please, if you have questions, just ASK!!! >> >> 4 days..... >> >> Cheers >> >> Mariano >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/listinfo/esug-list >> >> > > > -- > http://blog.ofset.org/hilaire > > > >

1 0

March 9, 2010

Hi nicolas could you give us an executive summary of the reasoning behind this change? Does this implies that we get Unicode by default? and that Unicode is integrated in the table of language (replacing latin1), so this way we do not have to check all the time is it 255? Stef I like all these opportunities to learn things.

2 2

[Pharo-project] Conseils for develop a grid
by nullPointer March 8, 2010

March 8, 2010

IÂ´m developing a grid for my UIBuilder. For the moment show a few cells and columns.The rows area is a ScrollPane widget with TableLayout policy. The rows header is another panel. In vertical scroll the behavior is correct, the rows scrolling and the header is fixed -> http://img43.imageshack.us/i/capturadepantalla200911w.png/ my problem is in the horizontal scroll, in that case rows area scroll good, but obviosly the header columns dont "match" with the rows columns, only is a panel -> http://img10.imageshack.us/i/capturadepantalla200911f.png/ IÂ´m catching the "scrolling" event, but i dont have a position reference for relocate the rows header panel. The rows area position donÂ´t change when is scrolled, is strange. I hope to me to have expressed wellâ¦ :| -- View this message in context: http://n2.nabble.com/Conseils-for-develop-a-grid-tp4028690p4028690.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

8 24