August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Gabriel Brunstein

?? i donÂ´t see your point, what is wrong with doing: 'foo' asSymbol asSelector On Tue, Aug 24, 2010 at 6:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> wrote: >> Or something like: >> self perform: #myMessage asSelector. >> It would be just one message in Symbol and not all the selector related protocol >> > > Yeah, and then code things like: > > 'foo' asSymbol asSelector > > great idea (pun intended)! > >> you can also leave the current behavior for that message if your >> prefer, in my opinion is not so bad... >> >> >> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> Following this logic, an object should perform: aSelector rather than aSymbol. >>> Thus we should then write (self perform: (#myMessage as: Selector)) in >>> order to keep up with conceptual clarity. >>> Unless of course we alter the # syntax and let it answer a Selector >>> rather than a Symbol ;) >>> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >>> >>> Seriously ? >>> >>> Nicolas >>> >>> 2010/8/24 Gabriel Brunstein <gaboto(a)gmail.com>: >>>> I like the idea to have a class Selector with all the protocol for >>>> selectors there, so any symbol doesnÂ´t have to understand selectors >>>> messages. >>>> Maybe you don't see short term advanteges of doing that, but I think >>>> that it will give conceptual clarity. >>>> >>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>> >>>>>> >>>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>>> >>>>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>>>> wrote: >>>>>>>> > Hi guys >>>>>>>> > >>>>>>>> > I'm thinking aloud... >>>>>>>> > I was wondering if we could not take advantage of a new class: >>>>>>>> > Selector. >>>>>>>> > MethodDict would only contain selectors and not symbols. >>>>>>>> > >>>>>>>> > I remember that I talked about that with hernan. >>>>>>>> > >>>>>>>> >>>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>>> such refactoring will be nothing more, >>>>>>>> but just renaming the class :) >>>>>> >>>>>> Personally I find it slightly annoying. Â Symbols are only used as selectors >>>>>> by convention, and the VM has placed no restriction on what objects can be >>>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>>> Symbols with SmallIntegers. Â Introducing a Selector class would obscure this >>>>>> possibility even more. Â However I find use of the term "symbol" where >>>>>> "selector" is meant even more annoying. Â I *hate* methodSymbol in >>>>>> MethodReference. Â It should be selector. >>>>>> 2Â¢ >>>>> >>>>> You're right, any object could be used as a selector, placed into >>>>> corresponding method dictionary, >>>>> but in practice syntax and compiler implies, that only symbols could >>>>> be used as selectors. >>>>> >>>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>>> restrictions on it (thanks to everyone's most liked deity). >>>>> In contrast, a Symbol, is a class, and instances of it can play >>>>> multiple roles, including being selector. >>>>> >>>>>> Eliot >>>>>> >>>>>>> >>>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>>> responsabilities of a Selector? >>>>>>> >>>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>>> numArgs:,value:, isKeyword, cull:,Â etc, seems more from Selector >>>>>>> >>>>>>> Â Cheers >>>>>>> >>>>>>> mariano >>>>>>> >>>>>>>> >>>>>>>> > Stef >>>>>>>> > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > Pharo-users mailing list >>>>>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-users mailing list >>>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> 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

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 25 August 2010 00:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Hmm.. i don't see obvious advantages. Do you? >> Most symbols (90% of cases), used as selectors, so it is likely that >> such refactoring will be nothing more, >> but just renaming the class :) >> >> Personally I find it slightly annoying. Â Symbols are only used as selectors by convention, and the VM has placed no restriction on what objects can be used as selectors so that, e.g. when aggressively shrinking one can replace Symbols with SmallIntegers. Â Introducing a Selector class would obscure this possibility even more. > Ok. I was thinking the inverse. But again I was gazing at my screen and this idea cross it so I did not think more than that. > >> Â However I find use of the term "symbol" where "selector" is meant even more annoying. Â I *hate* methodSymbol in MethodReference. Â It should be selector. > > > Me too :) > Actually I wanted to play with the following idea if I find a fun student. > We say ok we have packages/modules and we have a sealing mechanism and inside a seal package, ugly things can happen like aggressive inlining and one idea was also removing symbol method selectors. I'm curious what we could get. > I think this is a wrong route. I dont see how selectors/symbols is related to any kind of sealing mechanism. Selectors should be globally unique, otherwise things like #perform: will not function properly, as well as any inter-package communications, since multiple packages could use same selector(s). >> >> 2Â¢ >> Eliot >> >> >> Maybe because there are things implemented in Symbol or similar that are responsabilities of a Selector? >> >> I have no idea. But I did a quick search and methods like flushCache, numArgs:,value:, isKeyword, cull:, Â etc, seems more from Selector >> >> Â Cheers >> >> mariano >> >> >> > Stef >> > >> > >> > _______________________________________________ >> > Pharo-users mailing list >> > Pharo-users(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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.

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> wrote: > Or something like: > self perform: #myMessage asSelector. > It would be just one message in Symbol and not all the selector related protocol > Yeah, and then code things like: 'foo' asSymbol asSelector great idea (pun intended)! > you can also leave the current behavior for that message if your > prefer, in my opinion is not so bad... > > > On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Following this logic, an object should perform: aSelector rather than aSymbol. >> Thus we should then write (self perform: (#myMessage as: Selector)) in >> order to keep up with conceptual clarity. >> Unless of course we alter the # syntax and let it answer a Selector >> rather than a Symbol ;) >> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >> >> Seriously ? >> >> Nicolas >> >> 2010/8/24 Gabriel Brunstein <gaboto(a)gmail.com>: >>> I like the idea to have a class Selector with all the protocol for >>> selectors there, so any symbol doesnÂ´t have to understand selectors >>> messages. >>> Maybe you don't see short term advanteges of doing that, but I think >>> that it will give conceptual clarity. >>> >>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> >>>>> >>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> >>>>>> >>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>> >>>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>>> wrote: >>>>>>> > Hi guys >>>>>>> > >>>>>>> > I'm thinking aloud... >>>>>>> > I was wondering if we could not take advantage of a new class: >>>>>>> > Selector. >>>>>>> > MethodDict would only contain selectors and not symbols. >>>>>>> > >>>>>>> > I remember that I talked about that with hernan. >>>>>>> > >>>>>>> >>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>> such refactoring will be nothing more, >>>>>>> but just renaming the class :) >>>>> >>>>> Personally I find it slightly annoying. Â Symbols are only used as selectors >>>>> by convention, and the VM has placed no restriction on what objects can be >>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>> Symbols with SmallIntegers. Â Introducing a Selector class would obscure this >>>>> possibility even more. Â However I find use of the term "symbol" where >>>>> "selector" is meant even more annoying. Â I *hate* methodSymbol in >>>>> MethodReference. Â It should be selector. >>>>> 2Â¢ >>>> >>>> You're right, any object could be used as a selector, placed into >>>> corresponding method dictionary, >>>> but in practice syntax and compiler implies, that only symbols could >>>> be used as selectors. >>>> >>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>> restrictions on it (thanks to everyone's most liked deity). >>>> In contrast, a Symbol, is a class, and instances of it can play >>>> multiple roles, including being selector. >>>> >>>>> Eliot >>>>> >>>>>> >>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>> responsabilities of a Selector? >>>>>> >>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>> numArgs:,value:, isKeyword, cull:,Â etc, seems more from Selector >>>>>> >>>>>> Â Cheers >>>>>> >>>>>> mariano >>>>>> >>>>>>> >>>>>>> > Stef >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Pharo-users mailing list >>>>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-users mailing list >>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > 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.

Aug. 24, 2010

Re: [Pharo-project] PackageInfo >> printOn:

by StÃ©phane Ducasse

You remember when we tried to tag all senders and implementors result with a package (because I need this information when trying to get throw the junggle) and I thought that the printOn: could remind such notation. Now probably this solution is better/ Stef > I would change it to > > PackageInfo>>printOn: aStream > aStream print: self class; nextPutAll: ' named: '; print: self packageName > > That's basically the only solution that really makes sense. > > Lukas > > On 24 August 2010 22:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> may be { Collections-Weak } to make a displayed sign to denote packages. >> >> Stef >> >>> Or maybe we can add >>> >>> PackageInfo >> name >>> ^ self packageName >>> >>> >>> >>> >>> On Tue, Aug 24, 2010 at 4:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Hi. The current implementation of PackageInfo >> printOn: is this: >>> >>> printOn: aStream >>> >>> super printOn: aStream. >>> aStream nextPutAll: '(',self packageName,')'. >>> >>> So...it prints something like this: 'aPackageInfo(Collections-Weak)' >>> >>> most of the times I prefer to print 'Collections-Weak' >>> >>> in my image I change it to >>> >>> printOn: aStream >>> >>> aStream nextPutAll: self packageName. >>> >>> Do you think this can be useful for the rest or I just keep it in my image? >>> >>> Cheers >>> >>> Mariano >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010

Re: [Pharo-project] Fwd: About SPDF

by GermÃ¡n Arduino

Hehe, too much legal terms to me.....What we could do? Can modify, create a new package, etc? 2010/8/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > Begin forwarded message: > >> From: Bruce Badger <bruce_badger(a)badgerse.com> >> Date: August 24, 2010 11:10:04 PM GMT+02:00 >> To: GermÃ¡n Arduino <gsa(a)arsol.net> >> Cc: StÃ©phane Ducasse <stephane.ducasse(a)free.fr> >> Subject: Re: About SPDF >> >> Hi, >> >> The license in full, taken from the SPDF-Core package comment, is >> below. Â The license is pretty close to a BSD style license, but is a >> one-off concocted by the SPL WorldGroup lawyers (sorry Stephane). Â As >> the person who actually wrote the library I can tell you I would be >> perfectly happy for you to use the library, but I don't hold the >> copyright. Â The company SPL WorldGroup held the copyright when the >> library was written but they have been bought by Oracle now so I guess >> that means Oracle own the copyright. >> >> The intent of the license is to enable anyone to use the code as long >> as they don't bother SPL WorldGroup (now Oracle) about it. Â I know, >> because I was there when the license was put together, that the >> license was written to allow people to do just the kind of thing you >> would like to do ... but IANAL. >> >> Here is the text from the package comment which includes some notes >> and the license text: >> >> ~~~~ >> >> Look at the class side methods in PDFSelfTest for an idea of what the >> classes in this package can do for you. >> >> The code in this library is based upon the PDF Reference Manual V1.2. >> >> This library is made available under the following license: >> >> Preamble >> >> In the spirit of encouraging the continuing development of software >> for open computing environments and in the spirit of improving the >> quality of software generally, our goal is to provide this software to >> you free of charge and with the fewest possible restrictions. To >> achieve this, we asked our attorneys to draft an agreement which would >> permit you to do just about anything you lawfully wish with this >> software, while also preserving SPL's right to continue developing >> this and related software (something which we didn't feel the GNU GPL >> would allow us to do), and protecting SPL from excessive liability >> risks. We therefore offer this software, free of charge, according to >> the terms of the license below. >> >> The legal bit >> >> SPL WorldGroup, Inc. ("SPL") is willing to license the SPL Software >> and any Associated Materials (consisting of accompanying >> specifications, test suites and user documentation) to you only on the >> condition that you accept all of the terms and conditions in this >> Agreement. The SPL Software and Associated Materials are referred to >> collectively as the "SPL Technology." >> >> Please read the terms carefully before clicking on the "Accept" >> button, as by clicking on the "Accept" button you acknowledge that you >> have read this Agreement, understand it and agree to be bound by its >> terms and conditions. >> >> If you do not agree to these terms and conditions, SPL is unwilling to >> license the SPL Technology to you. You should click on the "Cancel >> Download" button to discontinue the installation process. >> >> 1. Licenses. >> >> 1.1 License. Subject to the terms and conditions contained herein, SPL >> grants you during the term of this Agreement a nonexclusive and >> fee-free right to download, install, copy, demonstrate, modify, create >> derivative works from, distribute, and use, in binary and or source >> code form, the SPL Technology, provided that you reproduce all >> copyright and other proprietary notices that are on the original copy >> of the SPL Technology. >> >> 1.2 Cross-License. Subject to the terms and conditions contained >> herein, you grant to SPL a nonexclusive and fee-free right to >> download, install, copy, demonstrate, modify, create derivative works >> from, distribute, and use, in binary and or source code form, any >> improvements, modifications or derivative works of the SPL Technology >> made by you and provided to SPL. >> >> 2. Restrictions. The SPL Technology is not designed or licensed for >> use in on-line control equipment in hazardous environments, such as >> operation of nuclear facilities, aircraft navigation or control, or >> direct life support machines. >> >> 3. Ownership. The SPL Technology is licensed, not sold, to you for use >> only under the terms of this Agreement, and SPL reserves all rights, >> including patent rights, not expressly granted to you. You own the >> media, if any, on which the SPL Technology is recorded, but SPL >> retains ownership of all copies of the SPL Technology itself. >> >> 4. Support And Updates. SPL is under no obligation to support the SPL >> Technology in any way or to provide updates or error corrections. >> >> 5. Disclaimer of Warranty. The SPL Technology is provided to you free >> of charge and "As Is," there is no warranty. To the maximum extent >> permitted by law, SPL expressly disclaims all warranties, including >> the implied warranties of merchantability, fitness for a particular >> purpose, and non-infringement. No oral or written information or >> advice given by SPL, its employees, distributors, dealers, licensors >> or agents shall increase the scope of the above warranties or create >> any new warranties. >> >> 6. Limitations of Remedies. >> >> 6.1 You acknowledge that: (a) the SPL Technology is experimental and >> provided to you only for the purposes set forth in this Agreement; (b) >> the SPL Technology may have errors, bugs, design flaws, defects or >> other deficiencies which cannot or will not be corrected by SPL; (c) >> use of the SPL Technology may result in unexpected results, loss of >> data or other unpredictable damage or loss to you; and (d) SPL is >> under no obligation to release the SPL Technology as a product of SPL. >> You will hold SPL harmless from any claims based on the use of the SPL >> Technology, from any claims that any product released by SPL is >> incompatible with the SPL Technology and from SPL's decision not to >> release the SPL Technology as a product. You will have the sole >> responsibility for adequate protection and backup of your data and/or >> equipment used with the SPL Technology. >> >> 6.2 Regardless of whether any remedy set forth herein fails of its >> essential purpose or otherwise, in no event will spl or its licensors >> be liable to you or to any third party for any lost profits, lost >> data, interruption of business, or other special, indirect, incidental >> or consequential damages of any kind, whether in contract, tort >> (including negligence) or otherwise, arising out of the use or >> inability to use the spl technology or any data supplied therewith, >> even if spl or its licensors have been advised of the possibility of >> such loss or damage and whether or not such loss or damages are >> foreseeable. >> >> 7. Term. This Agreement is effective until terminated. You may >> terminate this Agreement at any time by destroying all copies of SPL >> Technology. This Agreement will immediately and automatically >> terminate without notice if you fail to comply with any material term >> or condition of this Agreement. You agree upon termination to promptly >> destroy the SPL Technology and all copies thereof. >> >> 8. Export Law. The SPL Technology is subject to U.S. export control >> laws and may be subject to export or import regulations in other >> countries. You agree to strictly comply with all such laws and >> regulations and acknowledge that you have the responsibility to obtain >> such licenses to export, re-export or import as may be required. By >> downloading the SPL Technology, you agree to strictly comply with all >> of the United States and other applicable country laws and regulations >> when either exporting or re-exporting or importing the SPL Technology >> or any underlying information or technology. Further, you acknowledge >> that you are not a national of Cuba, Iran, Iraq, Libya, North Korea, >> Sudan or Syria or a party that is listed in the U.S. Table of Denial >> Orders or U.S. Treasury Department's list of Specially Designated >> Nationals. This SPL Technology is exported from the United States in >> accordance with U.S. Export Administration Regulations. Diversion >> contrary to U.S. law is strictly prohibited. The SPL Technology is >> restricted from being used for the design or development of nuclear, >> chemical, biological, weapons or missile technology without the prior >> permission of the U.S. Government. >> >> 9. General. Any action related to this Agreement will be governed by >> California law and controlling U.S. Federal law, and the United >> Nations Convention on Contracts for the International Sale of Goods >> and the choice of law rules of any jurisdiction shall not apply. If >> any provision of this Agreement is held to be unenforceable, that >> provision will be removed and the remaining provisions will remain in >> full force. This Agreement is the complete and exclusive statement of >> the agreement between us which supersedes any proposal or prior >> agreement, oral or written, and any other communications between us in >> relation to the subject matter of this Agreement. If you have any >> questions concerning this Agreement, you may contact by writing to >> SPL, Inc. at 75 Hawthorne Plaza, Suite 2010, San Francisco, CA, 94105. >> The SPL Technology is protected by United States Copyright Law and >> International Treaty. Unauthorized reproduction or distribution is >> subject to civil and criminal penalties. >> >> By downloading the SPL Technology, I acknowledge that I have read and >> fully understand the foregoing information and agree to abide by its >> terms and conditions. >> >> >> >> >> On 24 August 2010 15:56, GermÃ¡n Arduino <gsa(a)arsol.net> wrote: >>> Hi Bruce: >>> >>> We are (on the Pharo community) talking about your SPDF code to >>> generate PDF's from inside Squeak. >>> >>> We wish to have this package adapted to the newest versions of Pharo, >>> but the source code seem to by copyrighted, and we can't found the >>> urls >>> talking about, as http://wiki.cs.uiuc.edu/VisualWorks/PDF+Library or >>> www.splwg.com. >>> >>> Can you confirm us if we can take such source code and create a >>> squeaksource MIT licensed project to adapt it to Pharo? Â¿Is possible >>> to change >>> the license to MIT?. >>> >>> We wait your comments. >>> >>> Thanks you. >>> >>> -- >>> ================================================= >>> GermÃ¡n S. Arduino Â <gsa @ arsol.net> Â Twitter: garduino >>> Arduino Software & Web Hosting Â http://www.arduinosoftware.com >>> PasswordsPro Â http://www.passwordspro.com >>> ================================================= >>> >> >> >> >> -- >> Make the most of your skills - with OpenSkills >> http://www.openskills.org/ >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by StÃ©phane Ducasse

> > Hmm.. i don't see obvious advantages. Do you? > Most symbols (90% of cases), used as selectors, so it is likely that > such refactoring will be nothing more, > but just renaming the class :) > > Personally I find it slightly annoying. Symbols are only used as selectors by convention, and the VM has placed no restriction on what objects can be used as selectors so that, e.g. when aggressively shrinking one can replace Symbols with SmallIntegers. Introducing a Selector class would obscure this possibility even more. Ok. I was thinking the inverse. But again I was gazing at my screen and this idea cross it so I did not think more than that. > However I find use of the term "symbol" where "selector" is meant even more annoying. I *hate* methodSymbol in MethodReference. It should be selector. Me too :) Actually I wanted to play with the following idea if I find a fun student. We say ok we have packages/modules and we have a sealing mechanism and inside a seal package, ugly things can happen like aggressive inlining and one idea was also removing symbol method selectors. I'm curious what we could get. > > 2Â¢ > Eliot > > > Maybe because there are things implemented in Symbol or similar that are responsabilities of a Selector? > > I have no idea. But I did a quick search and methods like flushCache, numArgs:,value:, isKeyword, cull:, etc, seems more from Selector > > Cheers > > mariano > > > > Stef > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by Gabriel Brunstein

Or something like: self perform: #myMessage asSelector. It would be just one message in Symbol and not all the selector related protocol you can also leave the current behavior for that message if your prefer, in my opinion is not so bad... On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Following this logic, an object should perform: aSelector rather than aSymbol. > Thus we should then write (self perform: (#myMessage as: Selector)) in > order to keep up with conceptual clarity. > Unless of course we alter the # syntax and let it answer a Selector > rather than a Symbol ;) > Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) > > Seriously ? > > Nicolas > > 2010/8/24 Gabriel Brunstein <gaboto(a)gmail.com>: >> I like the idea to have a class Selector with all the protocol for >> selectors there, so any symbol doesnÂ´t have to understand selectors >> messages. >> Maybe you don't see short term advanteges of doing that, but I think >> that it will give conceptual clarity. >> >> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>> >>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> >>>>> >>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> >>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>> wrote: >>>>>> > Hi guys >>>>>> > >>>>>> > I'm thinking aloud... >>>>>> > I was wondering if we could not take advantage of a new class: >>>>>> > Selector. >>>>>> > MethodDict would only contain selectors and not symbols. >>>>>> > >>>>>> > I remember that I talked about that with hernan. >>>>>> > >>>>>> >>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>> such refactoring will be nothing more, >>>>>> but just renaming the class :) >>>> >>>> Personally I find it slightly annoying. Â Symbols are only used as selectors >>>> by convention, and the VM has placed no restriction on what objects can be >>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>> Symbols with SmallIntegers. Â Introducing a Selector class would obscure this >>>> possibility even more. Â However I find use of the term "symbol" where >>>> "selector" is meant even more annoying. Â I *hate* methodSymbol in >>>> MethodReference. Â It should be selector. >>>> 2Â¢ >>> >>> You're right, any object could be used as a selector, placed into >>> corresponding method dictionary, >>> but in practice syntax and compiler implies, that only symbols could >>> be used as selectors. >>> >>> Selector is just a _role_ , and really, VM doesn't puts too much >>> restrictions on it (thanks to everyone's most liked deity). >>> In contrast, a Symbol, is a class, and instances of it can play >>> multiple roles, including being selector. >>> >>>> Eliot >>>> >>>>> >>>>> Maybe because there are things implemented in Symbol or similar that are >>>>> responsabilities of a Selector? >>>>> >>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>> numArgs:,value:, isKeyword, cull:,Â etc, seems more from Selector >>>>> >>>>> Â Cheers >>>>> >>>>> mariano >>>>> >>>>>> >>>>>> > Stef >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Pharo-users mailing list >>>>>> > Pharo-users(a)lists.gforge.inria.fr >>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-users mailing list >>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 24, 2010

[Pharo-project] Fwd: About SPDF

by StÃ©phane Ducasse

Begin forwarded message: > From: Bruce Badger <bruce_badger(a)badgerse.com> > Date: August 24, 2010 11:10:04 PM GMT+02:00 > To: GermÃ¡n Arduino <gsa(a)arsol.net> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)free.fr> > Subject: Re: About SPDF > > Hi, > > The license in full, taken from the SPDF-Core package comment, is > below. The license is pretty close to a BSD style license, but is a > one-off concocted by the SPL WorldGroup lawyers (sorry Stephane). As > the person who actually wrote the library I can tell you I would be > perfectly happy for you to use the library, but I don't hold the > copyright. The company SPL WorldGroup held the copyright when the > library was written but they have been bought by Oracle now so I guess > that means Oracle own the copyright. > > The intent of the license is to enable anyone to use the code as long > as they don't bother SPL WorldGroup (now Oracle) about it. I know, > because I was there when the license was put together, that the > license was written to allow people to do just the kind of thing you > would like to do ... but IANAL. > > Here is the text from the package comment which includes some notes > and the license text: > > ~~~~ > > Look at the class side methods in PDFSelfTest for an idea of what the > classes in this package can do for you. > > The code in this library is based upon the PDF Reference Manual V1.2. > > This library is made available under the following license: > > Preamble > > In the spirit of encouraging the continuing development of software > for open computing environments and in the spirit of improving the > quality of software generally, our goal is to provide this software to > you free of charge and with the fewest possible restrictions. To > achieve this, we asked our attorneys to draft an agreement which would > permit you to do just about anything you lawfully wish with this > software, while also preserving SPL's right to continue developing > this and related software (something which we didn't feel the GNU GPL > would allow us to do), and protecting SPL from excessive liability > risks. We therefore offer this software, free of charge, according to > the terms of the license below. > > The legal bit > > SPL WorldGroup, Inc. ("SPL") is willing to license the SPL Software > and any Associated Materials (consisting of accompanying > specifications, test suites and user documentation) to you only on the > condition that you accept all of the terms and conditions in this > Agreement. The SPL Software and Associated Materials are referred to > collectively as the "SPL Technology." > > Please read the terms carefully before clicking on the "Accept" > button, as by clicking on the "Accept" button you acknowledge that you > have read this Agreement, understand it and agree to be bound by its > terms and conditions. > > If you do not agree to these terms and conditions, SPL is unwilling to > license the SPL Technology to you. You should click on the "Cancel > Download" button to discontinue the installation process. > > 1. Licenses. > > 1.1 License. Subject to the terms and conditions contained herein, SPL > grants you during the term of this Agreement a nonexclusive and > fee-free right to download, install, copy, demonstrate, modify, create > derivative works from, distribute, and use, in binary and or source > code form, the SPL Technology, provided that you reproduce all > copyright and other proprietary notices that are on the original copy > of the SPL Technology. > > 1.2 Cross-License. Subject to the terms and conditions contained > herein, you grant to SPL a nonexclusive and fee-free right to > download, install, copy, demonstrate, modify, create derivative works > from, distribute, and use, in binary and or source code form, any > improvements, modifications or derivative works of the SPL Technology > made by you and provided to SPL. > > 2. Restrictions. The SPL Technology is not designed or licensed for > use in on-line control equipment in hazardous environments, such as > operation of nuclear facilities, aircraft navigation or control, or > direct life support machines. > > 3. Ownership. The SPL Technology is licensed, not sold, to you for use > only under the terms of this Agreement, and SPL reserves all rights, > including patent rights, not expressly granted to you. You own the > media, if any, on which the SPL Technology is recorded, but SPL > retains ownership of all copies of the SPL Technology itself. > > 4. Support And Updates. SPL is under no obligation to support the SPL > Technology in any way or to provide updates or error corrections. > > 5. Disclaimer of Warranty. The SPL Technology is provided to you free > of charge and "As Is," there is no warranty. To the maximum extent > permitted by law, SPL expressly disclaims all warranties, including > the implied warranties of merchantability, fitness for a particular > purpose, and non-infringement. No oral or written information or > advice given by SPL, its employees, distributors, dealers, licensors > or agents shall increase the scope of the above warranties or create > any new warranties. > > 6. Limitations of Remedies. > > 6.1 You acknowledge that: (a) the SPL Technology is experimental and > provided to you only for the purposes set forth in this Agreement; (b) > the SPL Technology may have errors, bugs, design flaws, defects or > other deficiencies which cannot or will not be corrected by SPL; (c) > use of the SPL Technology may result in unexpected results, loss of > data or other unpredictable damage or loss to you; and (d) SPL is > under no obligation to release the SPL Technology as a product of SPL. > You will hold SPL harmless from any claims based on the use of the SPL > Technology, from any claims that any product released by SPL is > incompatible with the SPL Technology and from SPL's decision not to > release the SPL Technology as a product. You will have the sole > responsibility for adequate protection and backup of your data and/or > equipment used with the SPL Technology. > > 6.2 Regardless of whether any remedy set forth herein fails of its > essential purpose or otherwise, in no event will spl or its licensors > be liable to you or to any third party for any lost profits, lost > data, interruption of business, or other special, indirect, incidental > or consequential damages of any kind, whether in contract, tort > (including negligence) or otherwise, arising out of the use or > inability to use the spl technology or any data supplied therewith, > even if spl or its licensors have been advised of the possibility of > such loss or damage and whether or not such loss or damages are > foreseeable. > > 7. Term. This Agreement is effective until terminated. You may > terminate this Agreement at any time by destroying all copies of SPL > Technology. This Agreement will immediately and automatically > terminate without notice if you fail to comply with any material term > or condition of this Agreement. You agree upon termination to promptly > destroy the SPL Technology and all copies thereof. > > 8. Export Law. The SPL Technology is subject to U.S. export control > laws and may be subject to export or import regulations in other > countries. You agree to strictly comply with all such laws and > regulations and acknowledge that you have the responsibility to obtain > such licenses to export, re-export or import as may be required. By > downloading the SPL Technology, you agree to strictly comply with all > of the United States and other applicable country laws and regulations > when either exporting or re-exporting or importing the SPL Technology > or any underlying information or technology. Further, you acknowledge > that you are not a national of Cuba, Iran, Iraq, Libya, North Korea, > Sudan or Syria or a party that is listed in the U.S. Table of Denial > Orders or U.S. Treasury Department's list of Specially Designated > Nationals. This SPL Technology is exported from the United States in > accordance with U.S. Export Administration Regulations. Diversion > contrary to U.S. law is strictly prohibited. The SPL Technology is > restricted from being used for the design or development of nuclear, > chemical, biological, weapons or missile technology without the prior > permission of the U.S. Government. > > 9. General. Any action related to this Agreement will be governed by > California law and controlling U.S. Federal law, and the United > Nations Convention on Contracts for the International Sale of Goods > and the choice of law rules of any jurisdiction shall not apply. If > any provision of this Agreement is held to be unenforceable, that > provision will be removed and the remaining provisions will remain in > full force. This Agreement is the complete and exclusive statement of > the agreement between us which supersedes any proposal or prior > agreement, oral or written, and any other communications between us in > relation to the subject matter of this Agreement. If you have any > questions concerning this Agreement, you may contact by writing to > SPL, Inc. at 75 Hawthorne Plaza, Suite 2010, San Francisco, CA, 94105. > The SPL Technology is protected by United States Copyright Law and > International Treaty. Unauthorized reproduction or distribution is > subject to civil and criminal penalties. > > By downloading the SPL Technology, I acknowledge that I have read and > fully understand the foregoing information and agree to abide by its > terms and conditions. > > > > > On 24 August 2010 15:56, GermÃ¡n Arduino <gsa(a)arsol.net> wrote: >> Hi Bruce: >> >> We are (on the Pharo community) talking about your SPDF code to >> generate PDF's from inside Squeak. >> >> We wish to have this package adapted to the newest versions of Pharo, >> but the source code seem to by copyrighted, and we can't found the >> urls >> talking about, as http://wiki.cs.uiuc.edu/VisualWorks/PDF+Library or >> www.splwg.com. >> >> Can you confirm us if we can take such source code and create a >> squeaksource MIT licensed project to adapt it to Pharo? Â¿Is possible >> to change >> the license to MIT?. >> >> We wait your comments. >> >> Thanks you. >> >> -- >> ================================================= >> GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino >> Arduino Software & Web Hosting http://www.arduinosoftware.com >> PasswordsPro http://www.passwordspro.com >> ================================================= >> > > > > -- > Make the most of your skills - with OpenSkills > http://www.openskills.org/ >

Aug. 24, 2010

[Pharo-project] [update 1.2] #12110

by StÃ©phane Ducasse

12110 ----- - Network-Protocol fixes. Thanks SvenVanCaekenberghe Switched to proper use of #pathForFile. - WebClient-Core, WebClientTests Thanks Andreas Raab and SvenVanCaekenberghe/Philippe Marshall Sorry that it took so long to integrate WebClient, but we did not want that people think we were jumping on other works. I hope that our engineer will be able to contribute back to the package. Now I heard that several fixes coming from nice seasiders in pharo were not integrated. May be people are too busy, so we will see in the future. Now we should probably have a deeper look and integrate the new commits and also make sure the tests are green. Stef

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by John M McIntosh

On 2010-08-24, at 2:02 PM, Guillermo Polito wrote: > 5 + (1 to: 10) > > 5 + (1@5) > I would think that becomes 5 to: 15 and 6@11 BTW don't let 'garbage' asNumber -> 0 that just is a hassle when importing character data that should be a number, but because of a mistake upstream it's not a number. Silently converting to zero is just evil... -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 24, 2010